Hello
> Just popping in to say that we cannot const any parms to vtable methods.
> Parrot can't impose promises on the called code.
The attached patch drops the :const attribute in isa and get_class
methods. A lot of cast warnings disappear, and all tests pass in my
system.
--
Salu2
Index: src
On Sat, Apr 19, 2008 at 01:55:18PM -0700, Mark Glines wrote:
> On Sat, 19 Apr 2008 21:45:49 +0200
> NotFound <[EMAIL PROTECTED]> wrote:
> > The same applies to some parameters attributed as non null, and
> > explicitly called with NULL argument in several locations. How can a
> > cleaner figure wh
On Apr 20, 2008, at 2:37 PM, Mark Glines wrote:
Failure to do so
results in an "incompatible pointer" warning, just like any other kind
of prototype mismatch.
And that in my mind is equivalent to "can't."
xoxo,
Andy
--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance
On Sun, 20 Apr 2008 21:01:01 +0200
NotFound <[EMAIL PROTECTED]> wrote:
> On Sun, Apr 20, 2008 at 12:17 AM, Andy Lester <[EMAIL PROTECTED]>
> wrote:
>
> > Just popping in to say that we cannot const any parms to vtable
> > methods. Parrot can't impose promises on the called code.
Hi Andy!
Sure w
On Sun, Apr 20, 2008 at 12:17 AM, Andy Lester <[EMAIL PROTECTED]> wrote:
> Just popping in to say that we cannot const any parms to vtable methods.
> Parrot can't impose promises on the called code.
So take for example In default.pmc the method get_class:
VTABLE PMC *get_class() :const
That is
Just popping in to say that we cannot const any parms to vtable methods.
Parrot can't impose promises on the called code.
Take for example whatever the vtable method is to return the count of
elements in the array. You'd think this would easily be constable, but
we cannot at this point in time te
On Sat, 19 Apr 2008 21:45:49 +0200
NotFound <[EMAIL PROTECTED]> wrote:
Hi!
> I faced the same problem when trying to get rid of some warnings in
> order to help cage cleaning. Adding or removing a const in the
> parameters of many functions becomes a design change, not a simple
> code cleaning. I
Hello.
> This is where I ran into problems. Is get_string constable? It seems
> possible that someone somewhere would want to cache a stringification
> that was computationally intensive, for later reuse. So now (as
> bernhard kindly pointed out to me), this is starting to sound like a
> d
# New Ticket Created by Mark Glines
# Please include the string: [perl #53066]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=53066 >
Hi,
I've run into a design issue that I'm hoping for some discussion on.
Every time you