Re: Dynamic invocation vs. late/dynamic binding

Just a few drops of milk left.  The question is one of *meaning*, not of 
*substance*.  Of course it's still a cow, but that is only meaningful if I 
know what a cow is in the first place.  Sure, based on whatever the 
situation may be, I can gather all kinds of relevant information at 
runtime that can tell me the substance of whatever it is and can use 
dynamic data structures like JROM or whatever to record that information. 
But unless I have some type of a priori information about cows all of the 
information I collect is meaningless because I personally can't do 
anything meaningful with it.

Let's take a more practical example.  In an HTML form, why do we 
distinguish between an <input /> and a <textarea /> ?  They are both 
intended for collecting arbitrary text data of variable length.  It's not 
the *substance* of the tag that is important, it's the *meaning* of the 
tag.  One tag allows us to provide a single line of arbitrary text, the 
other allows us to provide text that includes line breaks, etc.  The 
browser, conforming to relevant specifications has a priori knowledge of 
the meaning of an <input /> tag vs. a <textarea /> tag.  The browser would 
never know what to do with those tags given nothing but their substance. 
Since it the browser understands the differences the tags meaning, it 
understands exactly what it needs to do when it encounters either of them.

Dynamic invocation and late/dynamic binding both require a certain amount 
of a prior information to assign context to the data and processes that 
are being dynamically invoked or bound.

- James Snell
     IBM Emerging Technologies
     jasnell@us.ibm.com
     (559) 587-1233 (office)
     (700) 544-9035 (t/l)
     Programming Web Services With SOAP
         O'Reilly & Associates, ISBN 0596000952

     Have I not commanded you? Be strong and courageous. 
     Do not be terrified, do not be discouraged, for the Lord your 
     God will be with you whereever you go.    - Joshua 1:9

Walden Mathews <waldenm@optonline.net> wrote on 01/07/2003 01:03:07 PM:

> James, I think you're missing the point.  Suppose you encounter some 
beast
> after dark.  It moos, so you strongly suspect it's a cow, but you can't 
see
> its
> coloring at all.  It's still a cow.  And now I feel as if I've milked 
this
> example.
> Thank you,

> Walden

> ----- Original Message -----
> From: "James M Snell" <jasnell@us.ibm.com>
> To: "Mark Baker" <distobj@acm.org>
> Cc: "Sanjiva Weerawarana" <sanjiva@watson.ibm.com>; 
<www-ws-arch@w3.org>;
> <www-ws-arch-request@w3.org>
> Sent: Tuesday, January 07, 2003 3:48 PM
> Subject: Re: Dynamic invocation vs. late/dynamic binding

> 
> >
> > > Of course you can!  All you need in order to create an abstraction
> > > is commonality.  Can't you "meaningfully" treat brown cows and black
> > > cows as cows?
> >
> > Not unless you *first* know: a) what "brown" is, b) what "black" is 
and c)
> > what a "cow" is.  But I don't thing that's the point. It's easy to 
collect
> > information about an object at runtime (e.g. what color the cow is,
> > whether you're using a square vs. a circle, etc)... it's a completely
> > different matter to assign *meaning* to that information.  E.g. what 
does
> > it *mean* to get a brown cow vs. a black cow?
> >
> > - James Snell
> >      IBM Emerging Technologies
> >      jasnell@us.ibm.com
> >      (559) 587-1233 (office)
> >      (700) 544-9035 (t/l)
> >      Programming Web Services With SOAP
> >          O'Reilly & Associates, ISBN 0596000952
> >
> >      Have I not commanded you? Be strong and courageous.
> >      Do not be terrified, do not be discouraged, for the Lord your
> >      God will be with you whereever you go.    - Joshua 1:9
> >
> > www-ws-arch-request@w3.org wrote on 01/07/2003 12:30:16 PM:
> >
> > > On Wed, Jan 08, 2003 at 01:21:22AM +0600, Sanjiva Weerawarana wrote:
> > > > > Late/dynamic binding means being able to manipulate squares and
> > circles
> > > > > with the Shape interface.  Dynamic invocation means being able 
to
> > > > > construct, for example, a "displaySquare" message without
> > compile-time
> > > > > knowledge of the full Square interface.
> > > >
> > > > That's fine - WSIF can handle that using something called JROM we
> > > > created (see alphaWorks again) to represent arbitrary schema typed
> > > > values.
> > > >
> > > > Clearly, in the absence of magic the information about the 
interface
> > > > (namely the data type defs) is needed at runtime at least 
(possibly
> > > > using xsi:type), so once that's available you're on easy street.
> >
> > > That seems to be something very different than what I'm talking 
about.
> > > Sorry, I don't see how it relates.
> >
> > > > > The former enables a client written to access Shape objects, to
> > later
> > > > > access triangles, ovals, hexagons, you name it.  The latter 
doesn't.
> > > >
> > > > I guess we're back to the REST vs. WS debate; your program cannot
> > > > manipulate those shapes in a meaningful way without an 
understanding
> > > > of what an oval is vs. a square.
> >
> > > Of course you can!  All you need in order to create an abstraction
> > > is commonality.  Can't you "meaningfully" treat brown cows and black
> > > cows as cows?
> >
> > > Where's the disconnect here?  Surely you've used polymorphism 
before?
> > > (which, in case you were wondering, the Shape example isn't trying 
to
> > > demonstrate .. exactly)
> >
> > > MB
> > > --
> > > Mark Baker.   Ottawa, Ontario, CANADA. http://www.markbaker.ca
> > > Web architecture consulting, technical reports, evaluation & 
analysis
> >
> >

Received on Tuesday, 7 January 2003 16:27:08 UTC