S&M vs. B&D (apoc6)

[Uri Guttman]

But mad or not, there are some good reasons to do just
that. First, it makes it possible to write interfaces to other
languages in Perl. Second, it gives the optimizer more
information to think about. Third, it allows the S&M folks to
inflict strongly typed compile-time semantics on each
other. (Which is fine, as long as they don't inflict those
semantics on the rest of us.) Fourth, a type system can be
viewed as a pattern matching system for multi-method dispatch.

shouldn't that be B&D and not S&M?

:-)

uri

--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
----- Stem and Perl Development, Systems Architecture, Design and Coding ----
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Damian Conway Perl Classes - January 2003 -- http://www.stemsystems.com/class

[Austin Hastings]

--- Uri Guttman <u...@stemsystems.com> wrote:
>
> But mad or not, there are some good reasons to do just
> that. First, it makes it possible to write interfaces to
> other
> languages in Perl. Second, it gives the optimizer more
> information to think about. Third, it allows the S&M folks to
> inflict strongly typed compile-time semantics on each
> other. (Which is fine, as long as they don't inflict those
> semantics on the rest of us.) Fourth, a type system can be
> viewed as a pattern matching system for multi-method
> dispatch.
>
> shouldn't that be B&D and not S&M?

I believe that depends on whether you consider strongly typed
compile-time semantics as being restrictive or painful.

I also suspect that showing too much acumen about the classification
may come back to haunt you at a Perl Conference ... ;->

=Austin

[Austin Hastings]

Having just read through the declaration bits (not the calling bits,
yet):

It is explicitly stated that "is rw" on a slurpy parameter distributes
across all the components.

Is there some way of differentiating array of const vs. array of rw?

That is, creating a hash or array that can be extended without
overwriting?

=Austin

[Damian Conway]

Austin Hastings wrote:

> It is explicitly stated that "is rw" on a slurpy parameter distributes
> across all the components.
>
> Is there some way of differentiating array of const vs. array of rw?
>
> That is, creating a hash or array that can be extended without
> overwriting?

I'm not sure I follow what you're asking for. Can you give a
hypothetical example?

Damian

[Mark J. Reed]

I think he wants to write a subroutine that takes an array parameter,
in which the subroutine is allowed to add elements to the array, but
is not allowed to modify any of the elements that are already there
on entry to the sub.

--
Mark REED | CNN Internet Technology
1 CNN Center Rm SW0831G | mark...@cnn.com
Atlanta, GA 30348 USA | +1 404 827 4754

[Austin Hastings]

Sure:

How do I specify an array which may be appended/pushed, but whose
values cannot change?

How do I specify a hash whose current keys/values are fixed, but which
can accept new keys/values?

Essentially, I'm distinguishing between change-to-object and
change-to-container.

=Austin

[Damian Conway]

Austin Hastings asked:

> How do I specify an array which may be appended/pushed, but whose
> values cannot change?

I believe you'd have to create a class for such things, derived from Array:

class AppOnlyArray is Array {
method STORE(int $index, $value) {
fail "Can't modify existing element"
if 0 <= $index < .length;
.SUPER::STORE($index, $value);
}
}

my @array is AppOnlyArray;

> How do I specify a hash whose current keys/values are fixed, but which
> can accept new keys/values?

Same story.

Damian

[Luke Palmer]

> I believe you'd have to create a class for such things, derived from Array:
>
> class AppOnlyArray is Array {
> method STORE(int $index, $value) {
> fail "Can't modify existing element"
> if 0 <= $index < .length;
> .SUPER::STORE($index, $value);
> }
> }
>
> my @array is AppOnlyArray;

This seems wrong to me... simply because it's easier to do in C++ than
it is in Perl... which has never been the case.

class Object;
void add_stuff(list<const Object>&) {...}

(Disregarding the fact that list<Object> doesn't, in fact, convert to
that...)

I would imagine that you could just declare a sub as:

sub add_stuff(@arr of Object is constant) {...}

Where the "is constant" presumably refers to the Object, not the
Array. Or does that go like this:

sub add_stuff(@arr of (Object is constant) {...}

Or does it go like something else?

Luke