Re: To :D or not to :D
[email protected] (Mark Overmeer)
| Newsgroups | perl.perl6.language |
|---|---|
| Message-ID | <[email protected]> |
* 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