As this has drifted off-topic, I've set the Reply-To on this to
POOP-group, please send replies there and not perl6-language.
On Sun, Jun 10, 2001 at 06:06:27PM -0500, Me wrote:
> > modeling of the whole database
>
> Doesn't seem like it's hard to do.
HA! Think "Lights Out": It...is...harder
Previously, on St. Elsewhere...
Simon(e) writes...
> But of course, I'm sure you already know what makes
> good language design, because otherwise you wouldn't
> be mouthing off in here...
Why is it that "Me" is *mouthing off*, but you're not? Why is that?
What makes you so *special*? The fact
At 11:07 PM 6/10/01 -0500, Me wrote:
> > > [joining 2d arrays]
>
> > I can't envisage this... Perhaps you could reveal an example.
>Seems simple to me. Perhaps you meant the concrete
>method and/or syntax to achieve the join, or to reference
>the two arrays, or to reference the result table. But t
On Sun, Jun 10, 2001 at 03:31:09PM -0700, Peter Scott wrote:
> He's right. I do a lot of DBI stuff with Oracle, and every so often I have
> a hankering for some kind of structured tied variable that would look like
> my database. Then I wake up and realize that modeling of a single table
> do
On Sat, Jun 09, 2001 at 10:57:25PM -0500, Me wrote:
> For this post (and hopefully thread), I'm interested in focusing
> on the fact that a multi-dimensional array syntax, whatever it
> might end up being, is clearly going to be a direct analog of
> tables
You're on the wrong list. All the langu
On Sun, Jun 10, 2001 at 04:05:20PM -1000, Tim Jenness wrote:
> At the risk of receiving a flame perl5 does not have multi-dimensional
> arrays. It has something that will do the job with a massive memory
> overhead ands lots of pain when dimensionality is high.
If you need it, I can finish off mu
On Sun, 10 Jun 2001, Sam Tregar wrote:
> On Sun, 10 Jun 2001, Me wrote:
>
> > Agreed. So long as you are talking about Perl 5's arrays.
> >
> > I disagree, if you are talking about 2 dimensional structures.
>
> You appear to have some fundamental misunderstanding about Perl 5. Perl 5
> does inde
> > [joining 2d arrays]
> I can't envisage this... Perhaps you could reveal an example.
Well, for a trivial example, here's two 2d arrays:
foo, bar, baz,
qux, quux, waldo
and
rab, foo, baz,
xuuq, qux, zug
Joining the first col of array 1 with the second col of
array 2 would
On Fri, 8 Jun 2001, Chris Hostetter wrote:
> After reading the Apocalypse & Exegesis articles, and seeing some examples
> of properties and the "is" operator, I'd like to suggest that the
> less-then operator be changed, so it is functionally equivalent to:
>
> $v2 = VALUE2;
> $v1
On Sun, Jun 10, 2001 at 03:31:09PM -0700, Peter Scott wrote:
> Even if your database is so simple that you do just want to model single
> tables, it would be easy to build atop DBI.
That'd be Tie::DBI, then.
This is the kind of thing that can be dealt with perfectly satisfactorily
with externa
At 06:06 PM 6/10/2001 -0500, Me wrote:
>Dataset from multiple 'joined' tables
>
> (A pair of joined tables can be visualized as two
> spreadsheet like grids that intersect at right angles
> with the intersection point being the joined column.
> The vertical slice picks out rows whe
> modeling of the whole database
Doesn't seem like it's hard to do.
With MD arrays, you are all but there anyway:
Table:
A 2d array.
Whatever is introduced to more directly support
handling MD arrays could very plausibly help in
more directly supporting handling of single tabl
Sam, I don't think we're on the same wavelength.
So a direct response seems pointless.
Larry himself said:
"while allowing multidimensional arrays to distinguish
between [this and that] in a manner more conducive to
database programming"
Ok, I did s/numerical/database/, but what's
At 05:58 PM 6/10/2001 -0400, Sam Tregar wrote:
>SQL via DBI. It's got a terrible learning curve but it's still around for
>a reason. You learn all about SQL's strengths if you start trying to
>replace it with arrays and hashes. Go forth and learn!
He's right. I do a lot of DBI stuff with Orac
On Sun, 10 Jun 2001, Me wrote:
> Agreed. So long as you are talking about Perl 5's arrays.
>
> I disagree, if you are talking about 2 dimensional structures.
You appear to have some fundamental misunderstanding about Perl 5. Perl 5
does indeed support multidimentional arrays:
my @matrix = (
> If array syntax really is a good analogy to database
> access (it's not)
Agreed. So long as you are talking about Perl 5's arrays.
I disagree, if you are talking about 2 dimensional structures.
If you don't think a two dimensional structure is a good
basic fit with a lot of database access, w
On Sun, Jun 10, 2001 at 01:56:21PM -0500, Me wrote:
> Yes. But if the syntax for arrays and db data are to
> be simultaneously the same and as ideal as possible,
> then either the core array syntax needs to be relatively
> ideal for relational db data, or one needs to redefine
> the array syntax t
On Sun, 10 Jun 2001, Me wrote:
> Yes. But if the syntax for arrays and db data are to
> be simultaneously the same and as ideal as possible,
> then either the core array syntax needs to be relatively
> ideal for relational db data, or one needs to redefine
> the array syntax to match a created db
> the end user is going to be able to
> redefine the syntax anyway,
Yes. But if the syntax for arrays and db data are to
be simultaneously the same and as ideal as possible,
then either the core array syntax needs to be relatively
ideal for relational db data, or one needs to redefine
the array s
On Sat, Jun 09, 2001 at 10:57:25PM -0500, Me wrote:
> B) any syntaces chosen for core features won't jar with what
> makes sense for the relational data sub-language (at least
> not accidentally).
But since the end user is going to be able to redefine the syntax anyway,
this isn't an issue.
--
20 matches
Mail list logo
