TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
For functions, types don't need to be treated specially from other
arguments
as in C++.
Could you give an example of what you mean in C++ and how Perl differs
from that?
In C++, types are not first-class objects. You can't pass a type as a
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
HaloO,
John M. Dlugosz wrote:
They are mixed! Perl treats types as first-class objects. For
functions, types don't need to be treated specially from other
arguments as in C++.
Looks like we need a third party ruling on that. Note that the
HO
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
The point I want to make is that we cannot think of P::C and M::C as
unrelated! There are the following typical uses of C in D:
1) as the type of the attribute $.a
2) as return type of m
3) as type of the local variable $b
Within the body
HaloO,
John M. Dlugosz wrote:
doit =has= a signature. Yes, I expect functions will be typechecked
when you try and assign one to a variable that declares a function
type. But the function is a value of that type, just like 5 is a value
of type Int, not itself a type.
What you consider as t
HaloO,
John M. Dlugosz wrote:
Larry, you've wanted to have class names used within a class be
virtual. With various degrees of conviction across the synopses, you've
wanted classes defined within a class to be overridable, or all classes
referenced by a class to be overridable, speculating on
I finished the first draft of a technical description for compositing roles.
It runs to 7 pages. Please see ยง16 in specdoc. -whew!-
--John
http://www.dlugosz.com/files/specdoc.odt and .pdf
HaloO,
John M. Dlugosz wrote:
They are mixed! Perl treats types as first-class objects. For
functions, types don't need to be treated specially from other arguments
as in C++.
Looks like we need a third party ruling on that. Note that the
HOW is the meta class object and the WHAT the protot
