Meta.proposal.prepend_with(Ruby Syntax)

Dear Rubytalkers,

I was thinking that one of the reasons for my previous suggestion (combined with the suggestion of moving both inside the brackets) was deemed troublesome was due to it looking too Smalltalkish, so perhaps the following is better?...

Core.proposal.semantics(The Double Bracket Notation)
Core.proposal.syntax('end' == '.')

CoreLibraries.proposal(New Collections Types)
CoreLib.supercede(List, Array)
CoreLib.supercede List, Array
CoreLib.supercede List, with: Array # Using Ruby 2.0 syntax.

StandardLibraries.proposal(Replace Webrick with Mongrel)
StdLib.new(NewLibraryNameHere)
StdLib.deprecated(OldLibraryNameHere)
StdLib.supercedes NewLibraryNameHere, OldLibraryNameHere

Libraries.proposal(What About If We Do X?)
Lib.new(AwesomeLibraryNameHere)
Lib.question(about: LibraryNameHere, Should I...?)
Lib.announcement(name: LibraryNameHere, version: 1.0)
Lib.ann name: LibraryNameHere, version: 1.0

Meta.discussion
Meta.announcement

Miscellaneous.question
Misc.announcement
General.announcement

I understand that there is doubt as to the usefulness and the likelikhood of uptake of this or any other syntax, but memes ain't memes unless they are at least given an initial vector.

I also realise that the strings should be quoted and that this proposal is a little too cute, but ideas are for floating; and sinking. Am I 100% serious about this? No. Am I 0% serious about this? No.

Anyway, I apologise if the previous attempted usage was irritating. For this to work there needs to be a certain amount of agreement, and it at least highlighted the issue for discussion at this time, even if without a comprehensive solution.

thoran

[etc]

Don't forget the effect this will have on the front page of your
newsreader/mail client. There's a limited amount of space for subject
lines.

martin

···

On 8/29/06, thoran @ thoran. com <thoran@thoran.com> wrote:

Dear Rubytalkers,

I was thinking that one of the reasons for my previous suggestion
(combined with the suggestion of moving both inside the brackets) was
deemed troublesome was due to it looking too Smalltalkish, so perhaps
the following is better?...

Core.proposal.semantics(The Double Bracket Notation)
Core.proposal.syntax('end' == '.')

thoran@thoran.com wrote:

Dear Rubytalkers,

I was thinking that one of the reasons for my previous suggestion
(combined with the suggestion of moving both inside the brackets) was
deemed troublesome was due to it looking too Smalltalkish, so perhaps
the following is better?...

<snip />

Thing is, it will take far less time to just read a line
or two of the post to figure out what it is about for the
next two years than it would to argue about which notation
would be best to use for the above purpose.

···

thoran

--
Posted via http://www.ruby-forum.com/.

thoran@thoran.com wrote:

Dear Rubytalkers,

I was thinking that one of the reasons for my previous suggestion (combined with the suggestion of moving both inside the brackets) was deemed troublesome was due to it looking too Smalltalkish, so perhaps the following is better?...

<snip />

Wow.

With all due respect, that's nuts.

···

--
James Britt

"The use of anthropomorphic terminology when dealing with
computing systems is a symptom of professional immaturity."
  - Edsger W. Dijkstra

You think wrong. The previous suggestion was deemed troublesome
because it's excessively verbose and nonsensical overall. Not that
this is any better.

If it *really* bothers you to see this much traffic on ruby-talk, use
the newsgroup interface and kill threads you don't want to read.

-austin

···

On 8/29/06, thoran @ thoran. com <thoran@thoran.com> wrote:

I was thinking that one of the reasons for my previous suggestion
(combined with the suggestion of moving both inside the brackets) was
deemed troublesome was due to it looking too Smalltalkish, so perhaps
the following is better?...

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * http://www.halostatue.ca/feed/
               * austin@zieglers.ca