cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Zope vs. Cocoon
Date Fri, 01 Mar 2002 13:51:41 GMT
Ovidiu Predescu wrote:
> 
> On Thu, 28 Feb 2002 16:30:39 +0100, Stefano Mazzocchi <stefano@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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------

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


Mime
View raw message