On Mon, Feb 01, 2010 at 06:12:16PM -0800, Jon Lang wrote:
: Larry Wall wrote:
: > But also note that there are several other ways to predeclare
: > types implicitly. The 'use', 'require', and 'need' declarations
: > all introduce a module name that is assumed to be a type name.
:
: Just to clarify: it's possible to define a module within a file,
: rather than as a file; and in fact the usual means of defining classes
: and roles is an example of this, since they are specialized kinds of
: modules. Correct? So if I' understanding this correctly, you should
: be able to say something like:
:
: use Foo;
: class Bar { ... has Foo $x ... }
: class Foo { ... }
:
: ...where the dots are stand-ins for irrelevant code. In effect, "use"
: tells the compiler that Foo is a noun, so that the parser knows the
: proper way to handle it. It also looks for the definition of Foo; but
: will it start screaming bloody murder if it can't find the definition
: right away? Have I failed to correctly tell it where to look for the
: definition? (i.e., do I need to say something like "use ::Foo" to let
: the parser know that the definition is in this file?)
You should use 'class Foo {...}' for a forward declaration of a class
in the same file, not a vacuous 'use' that implies strongly but wrongly
that the definitions are in another file. To look at it another way,
'use' is a real predeclaration, not a pre-non-declaration such as we
mean when we talk about "forward" declarations.
In other words, the above should really be giving you an illegal
redeclaration of class Foo, if Foo.pm did as advertised and created
a Foo type. You'd have to use 'augment' to do monkey typing like that.
There has been some speculation that we could allow proto and multi
classes when the intent is to scatter the definition around. But that
hasn't yet been determined to be a Good Thing. The compiler would like
to know that it can compose a class when it sees the trailing curly,
in case someone wants to use it in a subsequent BEGIN. Allowing multi
classes would necessarily subvert that at least till CHECK time, if
not till first use. You'd generally like to catch method name conflicts
no later than CHECK time.
Larry
