Re: Maybe we should think about Interface.isInterface functions again

On Jul 31, 2013, at 11:02 AM, Jonas Sicking wrote:

> On Wed, Jul 31, 2013 at 9:14 AM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>> On Wed, Jul 31, 2013 at 12:02 AM, Jonas Sicking <jonas@sicking.cc> wrote:
>>> It's not entirely clear to me how you mean that the isDirectory
>>> function would behave, or where it would live. Do you mean that we
>>> would add a isDirectory() function on all Directory instances which
>>> always return true?
>>> 
>>> That would mean that you write code like:
>>> 
>>> root.get("somename").then(function(result) {
>>>  if ("isDirectory" in result) {
>>>    // No need to actually call .isDirectory since it always returns true.
>>>    ... it's a directory ...
>>>  }
>>>  else {
>>>    ... it's a file ...
>>>  }
>>> });
>> 
>> That's a branding approach, but no, that's not what's intended.
>> Instead, the isFoo() method lives on the Foo interface object, not Foo
>> instances.
> 
> I guess I misunderstood Allen. I thought that he felt that
> Interface.isInterface functions "has a smell to it".
> 
> He also wrote "instance side isDirectory method" which made me think
> it was something different from Interface.isInterface.

Just to clarify, when I say instance-side I mean "properties on the prototype"

The terminology comes from that fact that in Smalltalk, Ruby, and ES6 class declarations  two parallel inheritance hierarchies   are automatically created.  The instance hierarchy that in JS links the prototype objects and the class hierarchy that in JS links the constructor objects.  A class definition defines both:

class Foo extends Bar { }
"instance-side method" = property of Foo.prototype or inherited from Bar.prototype, etc.
"class-side method" = method of Foo constructor or inherited from Bar constructor.  In class definition they are tagged with the somewhat misleading "static" keyword

If you try to create a diagram illustrating these parallel inheritance hierarchy you typically get a picture with two parallel lines going up form a constructor and its associated prototype object.  Hence, the "instance-side" and the "class-side" diagram.

Allen

Received on Wednesday, 31 July 2013 19:07:05 UTC