Interesting article on programming languages

[Dirk-Ulrich Heise]

Roey Katz schrieb in Nachricht <388f88ca.1925884 at news.erols.com>...
>The 'virtual classes' that Sweeney describes look to me an awful lot
>like something like this:
Looks very interesting!
By now, i solved the same problem (i think) by passing a class to the
constructor of some class in a framework, so as to have a sort
of "flexible factory":

class Base:
  def __init__(self,instclass)
    self.someinstance = instclass()

Maybe your approach makes it more readable... gotta try it out.

--
Dipl.Inform. Dirk-Ulrich Heise
hei at adtranzsig.de
dheise at debitel.net


Roey Katz schrieb in Nachricht <388f88ca.1925884 at news.erols.com>...
>The 'virtual classes' that Sweeney describes look to me an awful lot
>like something like this:
>
>
> class myClass:
>     def __init__( self ): pass
>     def doSomething( self ): print 'instantiating'
>
> class myClass2:
>     def __init__( self ): pass
>     def doSomething( self ): print 'instantiating (2)'
>
> class Base:
>
>     virtualClass = None
>
>     def __init__( self ):
>          self.inst = self.virtualClass()
>          self.inst.doSomething()
>
>
> class Derived1( Base ):
>     virtualClass = myClass
>
> class Derived2( Base ):
>     virtualClass = myClass2
>
>
>-----------------
>Isn't this the same thing?  I noticed that the virtual classes in
>Sweeney's code sample were all of the same base class;  to
>me, it seems that Python's object model is one of policy, not rules:
>if an object responds to a message, so be it, regardless of what
>*kind* of object it is -- so we have a little more freedom with
>Python.  Correct me if I'm redundant?
>
>I enjoy these constructs because they allow me to design flexible
>interfaces in the base class that I don't have to change at all as I
>add new features (sounds coherent?) I'm using this for a role playing
>game.
>
>
>Roey