Hello. Let me say first that several year ago I understand that any ambient of Smalltalk is more powerfull that any IDE Delphi for work with object, but this depend of your skills in one enviroment obviously. For that, I'm a more powerful programer in Delphi that in Smalltalk, for misfortune for me.
Second, let me say something about Delphi, just for information, anyway, correct me if I'm wrong: 2012/1/13 blake <[email protected]> > > On Thu, Jan 12, 2012 at 3:07 AM, laurent laffont < > [email protected]> wrote: > >> On Thu, Jan 12, 2012 at 11:07 AM, Denis Kudriashov >> <[email protected]>wrote: >> >>> 2012/1/12 Stéphane Ducasse <[email protected]> >>> >>>> >>>> but UI building is just one part of the story. If after you just get a >>>> long initialize methods then nothing gets really reused. >>>> >>>> >>> Yes, >>> It is reason why I hate VisualStudio and Delphi approaches. It is >>> imposible to create reusable components of user interface applications. >>> >> >> ??? Haven't use Delphi for +4 years but from Delphi 3 -> 7 it was not >> really hard to create reusable components, extend them and the IDE >> itself...... >> >> Laurent >> > > Perhaps I can interject usefully here. > > It isn't =hard= to create reusable components in Delphi. What it is is > =different=. Delphi adopted Visual Basic's "two classes of developers" > approach through delegation that hides all the actual object-oriented > programming from those who aren't comfortable with it. When you create an > event routine for a component on a form, the method is part of the form > class. > This method is for manage the event, not for do something that is really part of the model. A Form, no is part of the model. This is similar in VW: you coded your event handler method in the AplicationModel, that is like a Form in Delphi. > Rather horrifyingly, Delphi auto-creates forms by default and assigns them > to global variables, thus encouraging the practice of referencing a > =specific instance= of the class. Re-usable? It sets novices up to create > interfaces that don't even work properly with multiple instances of the > =same= form. > > No. The IDE automaticaly define a global variable and create code for create and assign a instance, but if you want more instances of same Form you can easy declare local variables and create new instance (on initialize of other instance or on the fly in accesor methods) and asign to. Same in Smalltalk.... And you can delete this automaticaly created code. Now, creating a component requires creating an actual object, then > compiling and installing it into the environment. It's not hard, but it's > easy to screw up, and fixing it requires going back into this other mode. > (It's not quite frozen once installed but it's not completely flexible, > either.) > I agree. I spend very much dead time in code-compile-debug cycle, but this is not mainly for use component, is for lack of a truth ambient of programing with object, Delphi is just an IDE. I screw up very often in Smalltalk, but I fix this directly in the debugger and go on :) > Components are supposed to be contract-less, meaning user type #1 can't > break them (at least from inside the object inspector). > > The upshot is that, yes, it is actually more difficult to create a > reusable UI. The delegation model encourages the mashing of the V and C > into the M, as it were. > mmm no. Again, a Form is not part of model, idealy this is for write event methods handlers. > You can easily make all the buttons on a form call the same code, but > buttons on a different form? Well, now you're looking at that compiled > component model. > In the Buttons you can use Actions for delegate the handler method of the click event. In general, you can assign method of a Form to events of controls in another Form, but I do not do often that becouse I only write a small code in the event handler in the Form for delegate to some model the work (DataModules). > > JBuilder (the Java equivalent of Delphi) sub-classed everything, which > seemed less than ideal, too. > > A Smalltalk-style equivalent could out-do this easily, since component > design wouldn't be any different from any other sort of programming. You > could use delegates OR subclass, and any subclass could instantly appear as > a component. > > I started using Smalltalk with VisualAge. While there were a lot of > limitations with the connector approach, I always thought it was kind of > cool: Being able to visually connect two objects so that a message from one > was matched up to a method the other was superior than "Intellisense" in a > lot of ways. > Finally, I like work with component in Delphi when I begin a proyect, but I guess that when I comming to make something more complex the IDE no aid much, you have to go at code editor and sometimes the utilization of components even hinder... In Smalltalk (Pharo) I have the problem at begining becouse I have to write all code by hand, but at end all work (coded, debug) is very simple all the time. Gastón
