[cap-talk] Deep attenuation, typed operations

[John Carlson]

Are people suggesting that web pages should have some kind
of interfaces defined?  Like OpenSearch for example?  Are we
talking inside a program, or inside the web, or both?  REST?
Web Services?

I love categorizing verbs.  Let's do more of it.  Nouns are BORING.
Let me start by suggesting that all acts cause state changes.  Acts can
be events (acts at a time and place), transport, consume,
produce, interfere, or control.  Any more high level categories
until we start digging deeper?
John
On Aug 17, 2007, at 4:25 PM, Sam Mason wrote:

> On Fri, Aug 17, 2007 at 01:44:08PM -0700, Jed Donnelley wrote:
>> From: Charles Landau <clandau at macslab.com>
>>> At 8:24 AM -0700 8/15/07, Jed Donnelley wrote:
>>>> If I don't know about object types and their operations that may
>>>> be present deep in the structure, then the default mechanism
>>>> 'fails' soft - that it it denies any unknown operations.
>>>
>>> Yes, but it fails.
>>>
>>>> However, with the extension that I mentioned in my last
>>>> message (wild cards, albut. etc.) one can certainly include
>>>> [read,*] to get the same effect.
>>>
>>> I think that is the effect you always want, and allowing specifying
>>> types (other than *) only invites failure.
>>
>> We could certainly start with that approach in an initial "CapDoc"
>> implementation.  One thing I like about that approach is that
>> it puts some amount of pressure on those implementing
>> objects to give comparable/compatible operations the same
>> name.  If that 'pressure' is adequate then perhaps nothing
>> like the more general typed mechanism for deep attenuation
>> will be needed.
>
> Haven't most "new" languages got some concept of a namespace precisely
> because people aren't this organised?  C had a flat namespace and
> look at all the ad hoc ways people tried to introduce a namespace
> hierarchy into it, prefixing the method name with the name of the
> package seemed to be popular.  Not looking at the type of the class  
> (or
> its super-types) seems to imply that the method names would go back to
> living in a flat namespace and would force people to go back to  
> fragile
> old ad hoc solutions.
>
> Yes naming similar things in similar ways is nice from the developers
> viewpoint, but you need some way of describing when two methods that
> happen to have the same name actually do something incompatible.  In
> typed object orientated languages the natural way of expressing this
> is through inheritance.  In our current example, there should probably
> be an interface with a single "read" method that all classes that we
> want to allow are derived from.  Ignoring the class hierarchy would be
> ignoring 10+ years of research into type systems.
>
>
> I do hope I've missed something obvious because this (methods  
> having the
> same name but not sharing a common supertype with the same method)  
> seems
> pretty fundamental stuff.
>
>
>   Sam
> _______________________________________________
> cap-talk mailing list
> cap-talk at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/cap-talk