* Patrick R. Michaud ([email protected]) [151012 20:25]:
> > > method new(MyClassHere:U: *@args) { ... }
> Keep in mind that what Perl 6 calls a "type object" isn't quite the
> same as class objects in other languages -- a Perl 6 typename is
> really an undefined instance of a class. In other words, the
> identifiers C<Int>, C<Rat>, C<Array> etc. refer to instances of
> those classes just like the literals C<3>, C<4/5>, and C<[1,2,3]> are
> instances of those classes. They share the same method spaces.
Yes, that what I started realizing when I saw all the pain Perl6 goes to
ignore the existence of a real "undef" in the language. (I follow Perl6
from a short distance since its start, read all original designs, but
this penny did not drop before, sorry)
The reasoning behind the output of
my $a; $a.say; $a = 1; $a.say being (Any) \n 1 \n
Which actually means
"unstantiated (Any)" versus "instantiated (Int) value=1"
for me personally painfully imbalanced.
my Car $a; my Car $b; Now I have two different types. Eh, wait
they are both Cars. No, not the same because types are real objects.
Or maybe a bit the same, because $a===$b is made to work. Ehhh...
Confused.
Is there any precedence in a succesful programming language where types
and values get mixed-up this way? There must be a hidden advantange,
which I do not see. Of course, syntactically this works, but Why?
For me, a "Car" is not "a vehicle which is not yet there", but is a
featural and functional template of a thing. The template describes the
interface of a car, not the instance of a car. A type is scientific,
an object is dull facts. Is that an old-fashioned, traditional idea
to be abandoned?
--
Regards,
MarkOv
------------------------------------------------------------------------
Mark Overmeer MSc MARKOV Solutions
[email protected] [email protected]
http://Mark.Overmeer.net http://solutions.overmeer.net
