[Pharo-project] New IDE alternative (was Misc. newbie questions)

blake dsblakewatson at gmail.com
Fri Jan 13 00:12:29 EST 2012


On Thu, Jan 12, 2012 at 3:07 AM, laurent laffont
<laurent.laffont at gmail.com>wrote:

> On Thu, Jan 12, 2012 at 11:07 AM, Denis Kudriashov <dionisiydk at gmail.com>wrote:
>
>> 2012/1/12 Stéphane Ducasse <stephane.ducasse at inria.fr>
>>
>>>
>>> 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. 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.

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.) 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. 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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20120112/3c3d1928/attachment-0001.html>


More information about the Pharo-dev mailing list