[ruby-talk:5781] Re: Dynamic languages, SWOT ?

Trimming mercilessly...
On Sat, 21 Oct 2000, Charles Hixson wrote:

> Hugh Sasse Staff Elec Eng wrote:
> 
> > On Sat, 21 Oct 2000, Charles Hixson wrote:
> >
> > parameters it only make sense for them to be in a subset of the
> > class heirarchy.   There is no way to express this constraint in Ruby
> 
> This is a run time check in a dynamically bound language.  I'm pretty sure

I think your example below gives a good reason why...
> 
> > or Python.  I have not really used Lisp or Smalltalk.  What I mean is
> > that it is a weakness [in typing?] to allow a parameter to be of *any*
> > class, for example when you know it must be a Numeric
> > or descendent of Numeric.  So does this weakness create a different
	[...] 
> address this in some way or other.  But notice that none of those are really
> dynamically bound.  Ruby's type system seems more akin to that of Self.  Run
> time checks are the only way to handle this.  If you want, you could raise an
> exception.  How else would you want this to be handled?  You can't know at

I was thinking that some tests could be done at compile time...so
I have not considered the run-time case.

> "compile" time what the type of the variable will be.  But it would be nice

I see freom below, why not.
> 
> > strength which outweighs the inability to type-check at compilation time?
> 
> Actually, there's nothing wrong with passing in a totally separately declared
> class, as long as it ended up with the appropriate API.  This is both a
> strength and a weakness, but I think more of a strength.  Consider:
> 
> There is a standard problem that models inheritance in classes and
> evolution.  Call it the bird problem.

Ah, the "Birds fly.  Except penguins, kiwis, ostriches,.." problem

> Now a Rubyesque solution would be a bit different than the normal one, and
> would involve mix-ins.
> consider constructing separate trees of inheritance, one for descent, and the
> other for capabilities.  To create a species, you inherit from the
> inheritance tree, and mix-in the appropriate capabilities.  Thus penguins
> don't end up with flight being denied, but just not being available.  I'm not
> sure that this is an appropriate construct, I'm still thinking about it, but
> it is a way in which mix-ins more than substitute for the lack of  multiple
> inheritance.
> 
At first I thought this ansered a different question, but now I see that
Mix-in effectively changes a "type", and pushes it outside the regular
class system.  That fundamentally damages class based type checking.

> >         Hugh
> >         [e-mail]
> 
> -- (c) Charles Hixson
> --  Addition of advertisements or hyperlinks to products specifically
> prohibited
> 
	Hugh>