This sort of thing is an excellent example of how method
selection based on calling context can help.
When somebody wants to overload existing keywords for their
slick new type, with overloading based on context they don't
have to touch the internals of the current methods at all.
raptor wrote:
> ]- One possible implementation of MATRICES is for example :
> As I read in perlguts-illustrated the array is represented as a array of
> POINTERS i.e.
>
> (pointer to $a[0], pto $a[1], pto $a[3]...., pto $a[n])
>
> then we can have f.e. "matrix" :
>
> matrix 10x5, @a;
>
> this just reorders the list in the following LIST-ARRAY structure :
>
> (pto $a[0] .. $a[9]) --next-> (pto $a[10] .. $a[19]) ---next-> (....)
>
> now we have chained-arrays. The benefit :
> (@a is now internally known for perl as MATRIX)
>
> push @a,@b;
>
> will push one by one all elements of @b into correspondending rows in @a
> matrix .... push is now executed in MATRIX CONTEXT.
> If you gotcha the idea then all splice, pop,shift, unshift will do their
> correspodending roles. (offcource there is some glitches such as what happen
> if the @b array is smaller/bigger the necessary elements for the matrix -
> then we can have fillwith zeros, with default value ... etc)
> THE other operator "unmatrix" just convert the matrix back to array..
> We can easly access say element 250 for example like $a[250] 'cause the
> exact position is is easy calculated, offcource the access will be little
> bit slower than normal array.....
> WHAT HAPPEN with HASHES ?!?
> May be we can look at them as TABLES...
>
> =====
> iVAN
> [EMAIL PROTECTED]
> =====
--
David Nicol 816.235.1187 [EMAIL PROTECTED]
:wq
