From: Michael Fellinger Date: 2006-05-08T09:02:24+09:00 Subject: Re: A major ruby annoyance! You probably should really invest some time into unittesting - it's worth a lot.And it is true, i spend at least half of my time on unittests (usingRSpec http://rspec.rubyforge.org/ and RubySeleniumhttp://rubyselenium.rubyforge.org) but have a solution that works (TM)and that i can use universally afterwards - always being confidentthat it behaves the way i want it to.I am sorry that I don't have time to answer lengthy on your mail - buti have to say that wrapping your head around unittesting is worth theeffort and really rewarding in the end.ah, and controlled declaration of variables would probably kill me :| On 5/8/06, Talha Oktay wrote:> 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 of> 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 variable> 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 double> 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 which> creates a class for you, but all of which all are non-standard modules.(Okay> 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-in> 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 is> 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 language> 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 caused> 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 perl> interpreter how strictly interpret the code. If perl can, whose latest major> 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 = exp> > >>> > >> is probably a bad sign anywhere but initialize and/or> > >>> > >> def something=(x)> > >> ...> > >> end> > >>> > >> likewise a = @something should almost always be a = 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> > >> >> >> >>>