From: Talha Oktay Date: 2006-05-08T08:18:49+09:00 Subject: Re: A major ruby annoyance! ------=_Part_23963_21612599.1147043926134 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi, Thank you all for the posts. They were all helpful and inspiring. I am neither live in States(I live in Turkey) nor a native speaker and Louis J. Scoras presented my problem beautifully much better than I could. So I especially thank him for that. First of all, I would like to say that the problem is valid for all types o= f variables. You can mistype a local variable name in the same block and you just create a second variable instantly. You can create an instance variabl= e anywhere in the class by adding @ in front of the variable name. If you mistyped an instance variable name in a method, probably the one you had properly initialized in your constructor, oops, sorry, you just created a new variable and had a brand new bug. If you are agile guy, and spent doubl= e time writing test for every little functionality, hopefully you would find it soon. Nothing protecting us from these kinds of errors. For global variables, constants they have all the same problem. What I have understood from all the posts, is that; there is no syntactical way for predeclaration of variables. All the solutions that you have provided includes partial solutions to the problem and includes some kind of error handling or conventional code and using them consistently which I do not want. According to me, they look ugly in such a consistent beautiful language. Besides that kind of custom solutions, according to me, just increase the complexity of the code. I would like to comment against posts which simply emphasizes that the interpreter can not think for us. I know that of course. What if we could tell the interpreter by saying that these are the variables that I am going to use in the class scope, in a block, in a method or in global scope etc. and ask the interpreter not to allow any other variable usage in the specified scope? Then the interpreter would definitely know our intent? I meant that. What I liked most about ruby how easy to write classes. While using ruby I had to mind shift myself persistently for using object oriented techniques in even small scripts. Writing classes, using objects are no longer burden. The built in attr_* removes all burden of getters and setters etc. For example to write a class in perl, java, c++ one has to implement all the getters or setters. In perl, one can use some custom modules from cpan whic= h creates a class for you, but all of which all are non-standard modules.(Oka= y some of the most widely used ones come with the distribution, but they are not part of the language) There are many other jewels that ruby has built-i= n or in its standard libraries. Ruby made unconventional, custom implementations made public and mainstream by making them built-in to the language as in attr_* example. On the other hand, for the problem that I present in my post, I am required to implement custom solutions which partially solve the problem. The problem that I stated here is one of the biggest sources of unintentional bugs. Ruby is supposed to cut down development time and reduce the unintentional complexity dramatically. It i= s one of most high level languages I have encountered. So I believe ruby should have not missed this feature. I really hope to see that ruby languag= e supports these with a new set of keywords in its next releases. Otherwise, = I do not think that ruby would be able get of out scripting and the lightweight web world or get into world big production systems. I believe ruby has a capacity to go forward if these kinds of doors could be closed. Of course, I talk without understanding the language guts. I know that variables are just references and everything is dynamically decided etc. It may not be easy to implement this. I do not know. But as the user/customer of ruby, I find that my development time does not dramatically increased as much as I expected. Yes I develop faster, but I lose the time that I gained in coding in testing. I prefer testing the functionality and the requirements not the guts. If I can run the code, I expect that language issues must be solved. I am very much suprised when I receive a no method error. Why do I have to run the statement just to see that object does not have that method implemented. I would like to deal with bugs that are cause= d by the misapprehension or misimplementation of the problem. I expect the compiler, interpreter to handle inconsistencies in the language usage itself. Ruby currently mixes the problem domain with the language domain because it does not let developer inform itself about language set the developer wants to use. I do not expect the language to be as strict as Ada by default but it should let the developer to configure how strict the interpreter should be. In perl, a developer can dynamically command the per= l interpreter how strictly interpret the code. If perl can, whose latest majo= r release about 12 years old, ruby has got to do this. I prefer a language that loudly shouts at with discriptive information when I do something wrong instead of running but producing erroneous results. Just because of this I have the habit of using zillions of assertions in my code when I developed in other languages. I have not been able to find an assertion module in ruby by the way (yes I know, you do not need it because it is very easy to write one or hey, another answer why do I ever need it..:)). I really admire you all guys because of your self confidence. Yes, as the Pickaxe books says strict typing made some code less portable and less reusable, but I am ready to make that compromise most of the time if my name depends on the correct functionality of the software I wrote. My comments are not to criticize ruby language and its community but to contribute to it's perfection. I already feel myself as rubyist but want this language make its way more broader domain, even better to my domain..:) Sincerely. On 5/7/06, Logan Capaldo wrote: > > > On May 7, 2006, at 5:00 AM, dblack@wobblini.net wrote: > > > Hi -- > > > > On Sun, 7 May 2006, Logan Capaldo wrote: > > > >> I would suggest using the attr_* methods or writing your own > >> accessors for any case where you might need to access an instance > >> varible > >> > >> @something =3D exp > >> > >> is probably a bad sign anywhere but initialize and/or > >> > >> def something=3D(x) > >> ... > >> end > >> > >> likewise a =3D @something should almost always be a =3D self.something > > > > It all depends. The attr_* family uses instance variables to do what > > it does, but there's no reason that should be viewed as the only or > > best or likeliest use of instance variables. It's layered on top of > > a subsystem (instance variables) that have other uses too. > > > > > > David > > > I wans't suggesting only using ivars for accessors, but I believe > strongly in the uniform access principle. Even if you using ivars for > something completely internal that no one sees, you should still wrap > the accesses to them in methods (private ones). > > > > -- > > David A. Black (dblack@wobblini.net) > > * Ruby Power and Light, LLC (http://www.rubypowerandlight.com) > > > Ruby and Rails consultancy and training > > * Author of "Ruby for Rails" from Manning Publications! > > > Paper version coming in early May! http://rubyurl.com/DDZ > > > > > ------=_Part_23963_21612599.1147043926134--