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 same short name.
Why is this the default?
Otherwise you lose this quite useful warning if the signatures didn't
matc
Hey Tim.
> I've kept an eye on Perl 6 and Parrot developments but I'm no expert in
> either. What I'd like *you* to do is make proposals (ideally fairly
> detailed proposals, but vague ideas are okay) for what a Perl 6 DBI API
> should look like.
> Keep in mind that the role of the DBI is to prov
Richard Nuttall wrote:
- support for automatically pulling database DSN information from a
~/.dbi (or similar) file. This is constantly re-invented poorly.
Let's just do a connect by logical application name and let the
SysAdmins sort out which DB that connects to, in a standard wa
On Fri, 19 Oct 2001 09:27:50 -0400
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > I am implementing a textbook algo in Perl (the textbook has
> > it written in C++) and have realized that if undef was to
> > numericize to NaN instead of 0, there are a lot of uninitialization
> > errors that would g
On Mon, 22 Oct 2001 12:18:16 -0400
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> > > $z[0] = 50;
> > > $z[2] = 20;
> > > @x = @y[@z];
> > In your code, should @x contain (@y[50,0,20]) or (@y[50,20]) or
> > (@y[50,undef,20]) ?
> @y[50,undef,20], which in Perl5 is @y[50,0,20].
An arbitrary and
On Mon, 29 Oct 2001 11:03:33 +1100 (EST)
Damian Conway <[EMAIL PROTECTED]> wrote:
> The Real Damian is the Damian inside each of us.
> You need to get in touch with your *own* inner Damian.
SETTING: Trendy bar.
DC: Hey, beautiful, how's it going? Say, do you have a little Damian in
you?
Damian Conway <[EMAIL PROTECTED]> writes:
> Of course, that's not to say that the particular C that's returned on
> failure-to-numerify mightn't have a property set that indicates the problem
> was not-a-numeric in nature.
Having more than one 'undef' value sounds like a recipe for internals
mad
On Wed, 10 Oct 2001 11:32:02 -0400
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> >Great idea, as well as sqrt(-1) returning 1i istead of raising the
> >exception.
> If we do them, yep. Currently no promises there.
If you do that, make sure it has to be enabled with a pragma. Having
complex numbers
I think Perl 6 should have a "but" keyword, as in:
if (defined $foo but $foo eq "") {
}
:-)
On Thu, 21 Feb 2002 06:50:13 -0600
[EMAIL PROTECTED] wrote:
> On Thu, Feb 21, 2002 at 12:30:11PM +0000, Sam Vilain wrote:
> > I think Perl 6 should have a "but" keyword, as in:
> > if (defined $foo but $foo eq "") {
> *scratches head*
> so... it negates t
[EMAIL PROTECTED] (Randal L. Schwartz) wrote:
> Sam> No, "but" is syntactically equivalent to "and" in English. It just
> Sam> implies that the second condition is not generally what you'd
> Sam> expect if the first was true.
> Maybe in the interest of huffman encoding, we could make it
> "even_
Aaron Sherman <[EMAIL PROTECTED]> wrote:
> An off-the-wall thought... If this is not the "expected" condition,
> should it have the extra meaning of an assertion? For example,
> could set $! to 'defined $foo but $foo eq ""' and, if -w was in use,
> issue 'warn "Exceptional condition: $!"'
Intere
se".
I notice that DBI no longer supports Perl releases <5.6. Seems enough
people are happy that 5.005 is obsolete.
--
Sam Vilain, [EMAIL PROTECTED] WWW: http://sam.vilain.net/
7D74 2A09 B2D3 C30F F78E GPG: http://sam.vilain.net/sam.asc
278A A425 30A9 05B5 2F13
I r
committees of professional standards-writers are
> pretty bad, and we're still a long way from that.
In the very young field of programming, aren't we all ignorant amateurs?
Any programmer who doesn't know that they are ignorant are almost
certainly instead arrogant.
--
Sam V
g
a class.
OO Code is; Classes, Attributes, Methods and Associations. How many
of these elements does Perl deal in?
And don't take offence at being called an amateur - the word literally
means `for the love of it'.
--
Sam Vilain, [EMAIL PROTECTED]
Thesaurus: ancient reptile with an excellent vocabulary
On Wed, 29 Jan 2003 18:04, Michael G Schwern wrote:
> On Tue, Jan 28, 2003 at 12:11:18PM +1300, [EMAIL PROTECTED] wrote:
> > This may sound like a silly idea but ...
> >
> > Has anyone considered removing with the syntactic distinction between
> > numeric and string indexing -- that is, between arr
nge the key
type
BAD: code that you have to rewrite if you change a key type
--
Sam Vilain, [EMAIL PROTECTED]
A closed mouth says nothing wrong; a closed mind does nothing right.
- anon.
ng the common concepts - then making them all
effectively obsolete by unifying the concepts into the language :-).
my 2c.
--
Sam Vilain, [EMAIL PROTECTED]
"I like a man who grins when he fights."
- Winston Churchill -
the primary elements of objects and so IMHO belong in the Perl 6 object
implementation. UML considers them pretty core, too.
Leave them out to carry on with the status quo of a myriad of subtly
different, non-interchangable approaches to associating classes.
--
Sam Vilain, [EMAIL PROTECTED]
If you think the United States has stood still, who built the
largest shopping center in the world?
RICHARD M NIXON
ccesses an attribute which is defined in both classes,
which does it get? I think that case (MI two classes with clashing
symbols) should be a hard run-time error. If attributes are declared
explicitly, then this enables this test. In Perl 5, the approach taken
with MI namespace clashes is to cross one's fingers ;).
--
Sam Vilain, [EMAIL PROTECTED]
"Understanding is a kind of ecstasy."
-- Carl Sagan
apsulated");
These tests perhaps illustrate the level to which I've made them similar;
is($car->get_owner(0), $joe, "Refs can look like arrays");
ok($car->owner_includes($joe), "Refs can look like encapsulated sets");
eval { $car->owner->includes($joe) }
On Thu, 06 Mar 2003 15:31, Brent Dax wrote:
> Sam Vilain:
> # > We musn't dictate style.
> #
> # No, but we should emanate good style. And I consider opening
> # two class'
> # namespaces into the same stash to be very bad style.
>
> We *must* support MI
e issues. What other practical approaches exist?
UML does not deal with persistence. It deals with specifying and modelling
objects.
I think that right now persistence fairly and squarely belongs outside of
Parrot :-).
--
Sam Vilain, [EMAIL PROTECTED]
I dont have any solution, but I certainl
re you
> are headed with
> this?
The paper appears to me to describe using serialisation of memory
structures to achieve persistence, which is another approach entirely.
Serialisation is good, but fails for more complicated memory structures.
--
Sam Vilain, [EMAIL PROTECTED]
The meek
e it too ugly. If they don't inherit the
methods they need then they'll just have to get a `method not defined'
error.
It just goes to show that MI is an ugly hack compared to using a servant
class. But that is not the point here; the point here is making good MI
semantics.
Sor
ons like classes, except that they'll
> mostly be auto-generated. However, if you need to insert code (as
> above) you can explicitly spell out your sub.
Certainly they could.
> What would be nice would be a convention for
> accessing/creating/querying/modifying them, so that when
ionship of Directory and
file. It is composite, indicating that Directory objects are composed of
files.
Associations *are* fundamental object things. Presenting them in terms of
attributes is the real hack.
--
Sam Vilain, [EMAIL PROTECTED]
It is necessary for me to establish a winner imag
lutely whipuptitudalicious.
[ poop-group list members: this is your cue to highlight the inadequacies
in what I have just stated, so that we can all model the input to our
object persistence tools in the same way in Perl 6. Speak now or hold
your peace for another generation of Perl. ]
-
On Sat, 08 Mar 2003 06:58, Dan Sugalski wrote:
> At 2:08 PM +1300 3/7/03, Sam Vilain wrote:
> >As long as mechanisms are put in place to allow modules to bypass
> > object encapsulation and private/public constraints, and given that
> > Parrot will have no XS,
>
> It wo
101 - 129 of 129 matches
Mail list logo
