[#1215] Tk widget demo; English Tk docs?; Java 1.2 Swing — "Conrad Schneiker" <schneiker@...>
Hi,
[#1218] Trivial FAQ bug — Dave Thomas <Dave@...>
[#1229] A vote for old behavior — Dave Thomas <Dave@...>
[#1232] Any FAQ requests, updates, ... — Dave Thomas <Dave@...>
[#1233] Singleton classes — Dave Thomas <Dave@...>
[#1263] Draft of the updated Ruby FAQ — Dave Thomas <Dave@...>
[#1307] Ruby/GTK 0.23 released — Hiroshi IGARASHI <igarashi@...>
Hi all,
From: Hiroshi IGARASHI <igarashi@ueda.info.waseda.ac.jp>
From: "Conrad Schneiker" <schneiker@jump.net>
On Fri, Feb 18, 2000 at 09:37:27PM -0500, Yasushi Shoji wrote:
[#1322] FAQ: Ruby acronyms — "Conrad Schneiker" <schneiker@...>
In the spirit of TABWTDI (there are better ways to do it), I'd like to
[#1341] Vim syntax file — Mirko Nasato <mirko.nasato@...>
Hi,
On Mon, Feb 14, 2000 at 05:44:39PM +0100, Mirko Nasato wrote:
[#1354] Say hi (bis) — Pixel <pixel_@...>
hi all,
[#1355] nice sample for functional stuff — Pixel <pixel_@...>
what about having map in standard (and map_index too)?
[#1373] Ruby Language Reference Manual--Glossary — "Conrad Schneiker" <schneiker@...>
I was going to print the Ruby Language Reference Manual when I noticed that
[#1376] Re: Scripting versus programming — Andrew Hunt <andy@...>
Conrad writes:
[#1379] Re: Yield — Andrew Hunt <andy@...>
>From: "Conrad Schneiker" <schneiker@jump.net>
[#1384] Re: Say Hi — mengx@...
My suggestion was to try to find a more comfortable method name (to me, and
[#1392] Re: Some Questions - Parameterised Types / Invariants — Andrew Hunt <andy@...>
>1. Parameterised Types / Template Classes
[#1398] Bignum aset — Andrew Hunt <Andy@...>
[#1488] Discussion happens on news.groups — Clemens Hintze <c.hintze@...>
Hi,
[#1508] Ruby/GTK and the mainloop — Ian Main <imain@...>
Hello Ian,
On Wed, Feb 23, 2000 at 02:56:10AM -0500, Yasushi Shoji wrote:
[#1516] Ruby: PLEASE use comp.lang.misc for all Ruby programming/technical questions/discussions!!!! — "Conrad Schneiker" <schneiker@...>
((FYI: This was sent to the Ruby mail list.))
From: "Conrad Schneiker" <schneiker@jump.net>
[#1528] ruby <=> python — Quinn Dunkan <quinn@...>
Hello! I'm new to ruby-talk, and mostly new to ruby. I'm making a document
[#1551] Ruby thread scheduling buglet — Ian Main <imain@...>
[#1569] Re: Ruby: constructors, new and initialise — Yukihiro Matsumoto <matz@...>
The following message is a courtesy copy of an article
[#1591] Certain char's not recognized by "." in regex? — Wes Nakamura <wknaka@...>
[#1592] Race condition in Singleton — Dave Thomas <Dave@...>
[ruby-talk:01445] Re: Yield
Conrad Schneiker writes: > From: Dave Thomas <Dave@thomases.com> > ... > Could we (the readers of this newsgroup)--in the interest of learn-ability, > teach-ability, comprehensibility, public friendliness, principle of least > surprise, not using Perl-like obscurities (e.g. bless), and everything else > that otherwise makes Ruby great--could we all agree on a better name for the > yield statement that would also be acceptable to Matz, and which could > co-exist for a year or so with a depreciated yield? Sorry, but I do not think, that a 'yield' should be deprecated. If we introduce a new statement besides 'yield', then ok! But we should not going the way to bear impression that Ruby is a new born language, IMHO. We can add new features, but we should not delete old ones; especially not *reserved keywords*! For all other changes, we should very careful! Ruby exists already for some years. Many people have used it to write applications. In Japan, Ruby has thrown away Python for programming. We should not come and change all this, because we do not like 'yield'. 'yield' is a key feature of Ruby. So the chance that much software has to be changed because of this deprecation, is high! I, for example, have no time to search and change all my software based on this. If I would try, my boss would ask me very seriously, if I think Ruby could be called 'finished' (in terms of ready-to-use), or if we should wait for one or two years. And then, he would not agree any longer, that I use it. Okay, all these applications could be changed by script, but also this involves much overhead. For example: all our programs are under version control, and not directly accessible to the developer after delivery. Too much trouble, I fear :-( > > At the moment, I strongly prefer callBlock because it is syntactically > self-documenting. I do not like this word. No that is not true! I do not like the 'wordWord' construct. Pffffhhh also not true. Before Ruby, I has used this 'wordWord' wording very often because I am too lazy to type the '_' ;-) But since I am programming Ruby I have changed my mind. That does not mean I do not use it anymore, but not in Ruby. Ruby use these wording only for class/module names. all methods are written in lower case with '_' between the words. Your 'callBlock' does not fit into this scheme! Ruby should consistent here. So my conclusion is: Let it as it is! If there should be a new keyword, than something like 'call_block'. The name of the new keyword has to fit into the current naming scheme. But *please* do not let 'yield' die!!! That would be a wrong decision, I fear. I would give Ruby the glance of an unfinished language. > > Group? > > Conrad > > (PS: likewise, can we agree to describe "destructive methods" as "change > methods"?) This would be better, IMHO. 'Destructive' means for me: destruct/destroy the object. But it is changed really! So I would vote for it! Just my two cents! \cle -- Clemens Hintze mailto: c.hintze@gmx.net