I agree having two types of examplers is sensible.
For examples sake let fExemplar be an exemplar constructed with new
Function and les oExemplar be the other one.
Now, I'm worried about magically making
fExemplar | oExemplar
work, would oExemplar have fExemplar or fExemplar.prototype in it's
To expand on inheritance operator, I would treat es:h classes as declarative
sugar for exemplars. Therefore it would make sense to have the extends
keyword work on exemplars.
We could use oExemplar extends fExemplar and have that make inheritance work
as expected
On Oct 14, 2011 8:38 AM, Jake
On Thu, Oct 13, 2011 at 4:14 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
Let me take a crack at tying to tie together all the pieces we have been
talking about.
Allen, I really appreciate your synthesis, thanks. I am able to follow some
of it because of my recent Q/A with the group. I
On Fri, Oct 14, 2011 at 5:54 PM, John J Barton
johnjbar...@johnjbarton.comwrote:
On Thu, Oct 13, 2011 at 4:14 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
Let me take a crack at tying to tie together all the pieces we have been
talking about.
Allen, I really appreciate your
On Oct 14, 2011, at 12:38 AM, Jake Verbaten wrote:
I agree having two types of examplers is sensible.
For examples sake let fExemplar be an exemplar constructed with new
Function and les oExemplar be the other one.
Now, I'm worried about magically making
fExemplar | oExemplar
One thing that worries me about the fsubo example is that
oExemplar.constructor.prototype does not exist. How is that circular
relation ship between .constructor and .prototype magically fixed?
the other issue of fixing | for oExemplar | fExemplar (and vica versa) is
does it break oObject |
On Oct 14, 2011, at 11:24 AM, Jake Verbaten wrote:
One thing that worries me about the fsubo example is that
oExemplar.constructor.prototype does not exist. How is that circular relation
ship between .constructor and .prototype magically fixed?
This is something I alluded to in my
7 matches
Mail list logo
