On Friday, 13. February 2009 20:30:24 Larry Wall wrote:
> While taking a shower I refined the design somewhat in my head,
> thinking about the ambiguities in package names when you're redefining.
> By my previous message, it's not clear whether the intent of
>
> multi package Foo::Bar {...}
>
>
Larry Wall wrote:
> Jon Lang wrote:
> : And with package versioning, you may not need an "is instead"
> : equivalent: if you want to "redefine" a package, just create a newer
> : version of it in a tighter lexical scope than the original package was
> : in. You can still access the original packag
On Fri, Feb 13, 2009 at 10:46:42AM -0800, Jon Lang wrote:
: And with package versioning, you may not need an "is instead"
: equivalent: if you want to "redefine" a package, just create a newer
: version of it in a tighter lexical scope than the original package was
: in. You can still access the o
Larry Wall wrote:
> Jon Lang wrote:
> : Well, we _do_ have a mechanism in place for adding to an existing
> : class (e.g., "class Foo is also { ... }"), and classes are a special
> : case of modules; so I don't see why you shouldn't be able to do
> : likewise with modules and even packages. That s
On Fri, Feb 13, 2009 at 09:44:12AM -0800, Jon Lang wrote:
: TSa wrote:
: > Does that imply that packages behave like C++ namespaces? That is
: > a package can be inserted into several times:
: >
: > package A
: > {
: > class Foo {...}
: > }
: > # later elsewhere
: > package A
: >
TSa wrote:
> Does that imply that packages behave like C++ namespaces? That is
> a package can be inserted into several times:
>
> package A
> {
> class Foo {...}
> }
> # later elsewhere
> package A
> {
> class Bar {...}
> }
>
> I would think that this is just different sy
On Fri, Feb 13, 2009 at 06:27:07PM +0100, TSa wrote:
> Does that imply that packages behave like C++ namespaces? That is
> a package can be inserted into several times:
>
>package A
>{
>class Foo {...}
>}
># later elsewhere
>package A
>{
>class Bar {...}
>
HaloO,
Jon Lang wrote:
Carl Mäsak wrote:
* A should be treated as a post-declared package.
Whatever this means, it sounds preferable. :)
It means that you can define package A without ever declaring it, by
declaring all of its contents using such statements as 'role A::B ',
'sub A::Foo', and
On Feb 11, 2009, at 2:46 PM, Carl Mäsak wrote:
Jon (>), Jonasthan (>>):
If we declared, for example:
role A::B {};
Then what should a reference to A be here? At the moment, Rakudo
treats it
as a post-declared listop, however I suspect we should be doing
something a
bit smarter? If so, w
Carl Mäsak wrote:
>> * A should be treated as a post-declared package.
>
> Whatever this means, it sounds preferable. :)
It means that you can define package A without ever declaring it, by
declaring all of its contents using such statements as 'role A::B ',
'sub A::Foo', and so on.
--
Jonathan
Jon (>), Jonasthan (>>):
>> If we declared, for example:
>>
>> role A::B {};
>>
>> Then what should a reference to A be here? At the moment, Rakudo treats it
>> as a post-declared listop, however I suspect we should be doing something a
>> bit smarter? If so, what should the answer to ~A.WHAT be?
>
On Wed, Feb 11, 2009 at 12:15 PM, Jonathan Worthington
wrote:
> Hi,
>
> If we declared, for example:
>
> role A::B {};
>
> Then what should a reference to A be here? At the moment, Rakudo treats it
> as a post-declared listop, however I suspect we should be doing something a
> bit smarter? If so,
Hi,
If we declared, for example:
role A::B {};
Then what should a reference to A be here? At the moment, Rakudo treats
it as a post-declared listop, however I suspect we should be doing
something a bit smarter? If so, what should the answer to ~A.WHAT be?
Thanks,
Jonathan
13 matches
Mail list logo
