inetbot web crawler
Main  |  Get access to the repository  |  API  |  The robot  |  Publications  |  Usenet Groups  |  Plainweb  | 
 inetbot - Groups (beta)

Current group: comp.object.

Re: Static vs dynamic

Re: Static vs dynamic  
kurbylogic at hotmail.com
From:kurbylogic at hotmail.com
Subject:Re: Static vs dynamic
Date:11 Jan 2005 22:50:17 -0800
JTK wrote:
> Phlip wrote:
> > The Ghost In The Machine wrote:
> >
> >
> >>>They /both/ suck!!
> >
> >
> >>Ok, somebody clue me in here; what, precisely, are we discussing?
:-)
> >
> >
> > Use http://groups.google.com to survey this group and "static vs
dynamic".
> >
> > Languages like Smalltalk and Ruby permit any foo.bar() call, if foo
is an
> > object with a bar. Languages like C++ and Java only permit the call
if foo
> > refers to an object of a class with a common base class containing
a virtual
> > 'bar()' method.
> >
>
> That desn't even make sense Philip. C++ most certainly allows
> "foo.bar()", whether bar() is declared virtual or not. Inheritance
or
> lack therof doesn't matter. One of us is missing something here....

To me the advantage of the dynamic language is not how polymorphic
behavior is implemented but rather the ability to change a "types
definition" dynamically at runtime. With the addition of anonymous
methods to C# I could perhaps fake something simalar using hashtables
and anonymous methods.

LUA:
foo = {}
foo.bar = function() print("I was created at runtime!") end
foo.bar()

C#
class Program
{
delegate void method();
static void Main(string[] args)
{
IDictionary foo = new Hashtable();
//add methods to this object
foo["bar"] = new method(delegate()
{ Console.WriteLine("I was created at runtime!"); });

// call the method
((method)foo["bar"])();
}
}

Adding methods at runtime isn't possible with strongly typed classes.
So why on earth might we want to do this anyway? wouldn't a subclasses
and/or object wrappers work instead...?
Possibly not, perhaps for the same reason most Windows control classes
have a Tag property. The Tag property has absolutely no effect on the
control behavior at all its sole purpose is to allow the client to hang
additional properties such as to associate a recordId with items in a
listbox for example. Subclassing requires control of the creation
process. A wrapper might be added after creation however the wrapper
will have a completely different identity and thus unless you already
know what item it wraps or have a method to obtain an existing wrapper
its not very useful for adding properties as rewrapping it would just
create new instances of empty/default properties.
For example say listitems are inserted by listitem item =
listbox.add(partDescription); without the ability to add partId to the
item we may need to get more created such as using a hashtable to
associate the additional the partId with the item's index in the
listbox; partIds[item.Index] = partId and somehow try to ensure that
the map and listbox remain synchronized. In a dynamic language the
simplest solution may be to just add a partId property to the item at
runtime or better yet add the desired behavior item.DisplayDetails =
function() { partDialog.Show(partId); } and the item "type" now
includes a DisplayDetails() function as if perhaps it always had one.
- Kurt
   

Copyright © 2006 inetbot   -   All rights reserved