[Millscript-developer] Re: MillScript 10

[Kevin R. <mo...@us...>]

On Thursday 20 Jan 2005 12:47, Kevin Rogers wrote:
> The main sticking point for classes are constructors and how they should be
> implemented. Specifically there is no "new" operator for constructing an
> instance of a class, you call a constructor like any other normal
> procedure, except a constructor is guaranteed to return one result - an
> instance of the relevant class.
>
> To get constructors working completely requires that you are able to apply
> a class like any other procedure. This is a concept referred to as an apply
> action, i.e. the action taken when an object is applied. I'm slightly
> concerned about the approach and wondering if this is really as simple as
> it seems, i.e. in a apply expression you check the type of the object being
> applied and branch out to the relevant apply-action? (and trying to do as
> much as possible at compile-time rather than run-time)
>

On a related note, to clarify - is the behavior of the class expected to 
change depending on how the class is defined? e.g.

# Default no-args constructor provided automatically
# --> Class is applied as a procedure
define class One
  slot a = "hello";
enddefine;

# No default no-args constructor, single arg constructor with same name
# as class defined
# --> Class is applied as a procedure with one arg
define class Two
  define init Two( x ) =>
    # do something special with x
  enddefine;
enddefine;

# No default constructor, constructor with different name defined
# --> Class cannot be applied
# --> new init procedure declared and applied as normal
define class Three
  define init SomeOtherName() =>
  enddefine;
enddefine;

# Constructors with different names.
# --> Class can be applied
# --> new init procedure declared and applied as normal
define class Four
  define init Four() => ... enddefine;
  define init SomeOtherName() => ... enddefine;
enddefine;


---
Kevin