Re: Zope vs. Cocoon

[Ovidiu Predescu <ov...@cup.hp.com>]

On Thu, 28 Feb 2002 16:30:39 +0100, Stefano Mazzocchi <st...@apache.org> wrote:

> > Any method call in python is done thru reflection.  Calling a
> > method in python means looking in the attribute hashmap of the
> > object for a function object of that name.  You can modify the
> > values of the hashmap and even add or delete methods at runtime.
> > 
> > Python interfaces, are defined thru documentation only, not a
> > static type system. That's very handy for a language, which's
> > greatest strength is rapid prototying.
> 
> Yes, well, might be handy for rapid prototiping, but I consider it a
> limitation because I consider strong type safety a must in order
> create solid architectures.

Not really. Do you know MacOS X? Do you know the language on which
it's built?

It's called Objective-C, and is an object-oriented, C-based, compiled
language, very similar with Smalltalk in its dynamic nature. The
compiler does type checking, but at runtime you can do whatever you
want with objects. You can even send messages to objects that don't
implement them.

You'd think this is not a useful feature, but it was on NeXTSTEP (the
precursor of MacOS X) where I saw more than 10 years ago the best
distributed objects technology I've seen so far. Remote objects would
appear as local objects in you application, and you could import any
object from a remote application, without having to have the system
create any class stubs for you. The implementation was done in only
two classes, Connection and Proxy. Proxy was a special class that
implemented no methods at all (well, except a special one). It would
instead be used to represent a remote object. When you send a message
to this class, the special method would be invoked. As arguments to
this method you had the original name of the method that was invoked,
plus all the parameters of the call. This method would use the
associated Connection instance to send them to the remote application,
where the actual invocation happened. The results would be simply
returned over the wire, and returned from the local method invocation
as if everything was local.

Many other things, including the GUI framework, with the best
architecture I've seen ever, benefited from this dynamic and un-typed
language. The whole system was robust, easy to use and to program more
than 10 years ago. Even now, beside MacOS X, you can hardly see
systems so nicely architected as this one. I think they rightly say
that languages shape the way we think.

Greetings,
-- 
Ovidiu Predescu <ov...@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org

Re: Zope vs. Cocoon

[Stefano Mazzocchi <st...@apache.org>]

Ovidiu Predescu wrote:
> 
> On Thu, 28 Feb 2002 16:30:39 +0100, Stefano Mazzocchi <st...@apache.org> wrote:
> 
> > > Any method call in python is done thru reflection.  Calling a
> > > method in python means looking in the attribute hashmap of the
> > > object for a function object of that name.  You can modify the
> > > values of the hashmap and even add or delete methods at runtime.
> > >
> > > Python interfaces, are defined thru documentation only, not a
> > > static type system. That's very handy for a language, which's
> > > greatest strength is rapid prototying.
> >
> > Yes, well, might be handy for rapid prototiping, but I consider it a
> > limitation because I consider strong type safety a must in order
> > create solid architectures.
> 
> Not really. Do you know MacOS X? Do you know the language on which
> it's built?
> 
> It's called Objective-C, and is an object-oriented, C-based, compiled
> language, very similar with Smalltalk in its dynamic nature. The
> compiler does type checking, but at runtime you can do whatever you
> want with objects. You can even send messages to objects that don't
> implement them.
> 
> You'd think this is not a useful feature, but it was on NeXTSTEP (the
> precursor of MacOS X) where I saw more than 10 years ago the best
> distributed objects technology I've seen so far. Remote objects would
> appear as local objects in you application, and you could import any
> object from a remote application, without having to have the system
> create any class stubs for you. The implementation was done in only
> two classes, Connection and Proxy. Proxy was a special class that
> implemented no methods at all (well, except a special one). It would
> instead be used to represent a remote object. When you send a message
> to this class, the special method would be invoked. As arguments to
> this method you had the original name of the method that was invoked,
> plus all the parameters of the call. This method would use the
> associated Connection instance to send them to the remote application,
> where the actual invocation happened. The results would be simply
> returned over the wire, and returned from the local method invocation
> as if everything was local.
> 
> Many other things, including the GUI framework, with the best
> architecture I've seen ever, benefited from this dynamic and un-typed
> language. The whole system was robust, easy to use and to program more
> than 10 years ago. Even now, beside MacOS X, you can hardly see
> systems so nicely architected as this one. I think they rightly say
> that languages shape the way we think.

I've never programmed in Objective-C, nor had the pleasure to play with
a NeXT, nor had (yet!) the chance to develop natively with MacOSX (I
just did some porting of a few unix applications over to OSX, but that's
nothing to be proud of) and I never had the need to use RMI, RPC, CORBA
or any other remote invocation technologies (besides regular
client-server stuff), so I should probably just shut up...

.. but design concepts like object polymorphism, interface casting,
proxies and the like, I think they are 'half between' complete type
safety (which is, admittedly, hard to modularize since you must know
'a-priori' all the contracts with the rest of the world) and complete
lack of type safety (scripting-like languages where runtime errors are a
real plague).

In media stat virtus.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org