It's possible that we could do the following:
1) All subs (and methods) are considered multi 'under-the-hood'.
2) If the first declaration is explicitly 'multi', then you (or
others) can provide additional overloads (using 'multi') that won't
trigger warnings.
3) If the first declaration /doesn'
On Wed, Jul 06, 2005 at 11:47:47PM +0100, Piers Cawley wrote:
: Or you could use a global, but globals are bad...
Globals are bad only if you use them to hold non-global values.
In this case it seems as though you're just going through contortions
to hide the fact that you're trying to do somethin
Piers Cawley wrote:
Then the harness that actually sets up the application would simply do
use Logger::DBI :dsn<...>, :user<...>, :password<>
and Logger::DBI would install itself as the default Logger class.
The question is, how does one write Injected to make this work? Or what
features
Maxim Sloyko wrote:
But this is not the point. The point was that usage of some file with
passwords by *DEFAULT* is not the way to go, IMHO. It raises more
problems than it solves.
Can you give an example of such a problem that wasn't already there?
Just to be clear, the file would only need
So, I got to thinking about stuff. One of the more annoying things about
writing nicely decoupled objects and applications are those occasions where you
want an object to be able to create objects in another class. Say you've
provided a singleton interface to your logging system. The naive implemen
Larry,
Okay, I reviewed A12, and I think I have now managed to implement the
proper object creation behavior in the meta model.
Currently it is somewhat limited, but this is the order of events (as I
understand it from A12).
- First Object.new calls Object.bless passing all named arguments.
On Wed, 6 Jul 2005, Juerd wrote:
I think the problem one has is much bigger even if a day *number* is
ever displayed. Then beginning with 1 because that's where most humans
begin counting, is wrong. It's a technical thing, and that should be
kept as simple as possible, and as technical as possib
On Wed, Jul 06, 2005 at 03:29:36PM +0200, "TSa (Thomas Sandlaß)" wrote:
: HaloO Larry,
:
: you wrote:
: >Well, there's something to be said for that, but my gut feeling says
: >that we should reserve the explicit generic notation for compile time
: >processing via roles, and then think of run-time
On Wed, Jul 06, 2005 at 11:28:47AM -0400, Stevan Little wrote:
: It seemed to me from A12 that submethods are meant to define an
: interface of some kind, the BUILD/DESTROY submethods being the perfect
: example. However this means that BUILDALL and DESTROYALL need to be
: fairly magical. I say
On Wed, Jul 06, 2005 at 04:19:40PM +0200, "TSa (Thomas Sandlaß)" wrote:
: Stevan Little wrote:
: >You seem to indicate that submethods are not to be used on instances,
: >and instead to be used on the underlying metaclass. I did not see
: >anything of the sort in (Syn|Apoc)12 or in my (limited) s
Juerd wrote:
I think the problem one has is much bigger even if a day *number* is
ever displayed. Then beginning with 1 because that's where most humans
begin counting, is wrong. It's a technical thing, and that should be
kept as simple as possible, and as technical as possible, for easier
compat
Thomas,
On Jul 6, 2005, at 10:19 AM, TSa (Thomas Sandlaß) wrote:
S12 says in the section Submethods: "A submethod is called only when a
method call is dispatched directly to the current class."
And without finding a reference I think it was said that "the invocant
of a submethod is a class obj
The Perl 6 summary for the week ending 2005-07-05
My, doesn't time fly? Another fortnight gone and another summary to
write. It's a hard life I tell you!
This week in perl6-compiler
Where's everyone gone?
It seems that most of the Perl 6 compiler development is being discussed
at
On Wed, Jul 06, 2005 at 12:58:44 +0100, Piers Cawley wrote:
> Then write yourself a module, call it 'multiplicity' say, which would allow
> you
> to say
>
> use multiplicity;
>
> sub foo (...) {...} # foo is a multimethod, even if there's already a
> 'SMD'
> #
Stevan Little wrote:
You seem to indicate that submethods are not to be used on instances,
and instead to be used on the underlying metaclass. I did not see
anything of the sort in (Syn|Apoc)12 or in my (limited) search of the
mailing list. Can you point me to that information?
S12 says in th
HaloO Larry,
you wrote:
Well, there's something to be said for that, but my gut feeling says
that we should reserve the explicit generic notation for compile time
processing via roles, and then think of run-time lazy type aliasing
Could you explain what exactly 'run-time lazy type aliasing' is
Thomas,
On Jul 6, 2005, at 7:14 AM, TSa (Thomas Sandlaß) wrote:
One entry for &bar:(Foo) and one for &bar:(MetaClass[Foo])?
You seem to indicate that submethods are not to be used on instances,
and instead to be used on the underlying metaclass. I did not see
anything of the sort in (Syn|Apo
On Wednesday 06 July 2005 06:39 am, Maxim Sloyko wrote:
> But this is not the point. The point was that usage of some file with
> passwords by *DEFAULT* is not the way to go, IMHO. It raises more
> problems than it solves.
To tack onto that, IMO it would make more sense if the password situation
Steve Sapovits wrote:
Maxim Sloyko wrote:
I don't think this solves the problem, because what I usually want is
the user to be able to use the application, but unable to see the DB
password. So the user should have "read" permission set for the file,
but on the other hand he shouldn't. It's n
Yuval Kogman <[EMAIL PROTECTED]> writes:
> On Fri, Jul 01, 2005 at 13:42:34 +1200, Sam Vilain wrote:
>> Yuval Kogman wrote:
>> >As I understand it SMD is now not much more than a mechanism to
>> >place a constraint on the MMD, saying that there can only be one
>> >method or subroutine with the sam
Stevan Little wrote:
The concept of non-inherited infrastructural methods is fairly simple to
accomplish in the meta-model, by just giving submethods their own
dispatch table inside the metaclass. However where I am somewhat
confused is in how and when they get called.
I think the question is
Maxim Sloyko wrote:
I don't think this solves the problem, because what I usually want is
the user to be able to use the application, but unable to see the DB
password. So the user should have "read" permission set for the file,
but on the other hand he shouldn't. It's not not a problem for We
22 matches
Mail list logo
