Nicholas Clark writes:
> On Sun, Mar 20, 2005 at 10:54:15PM -0700, Luke Palmer wrote:
>
> > in the same form if it does come back. So consider 6.0 its usage
> > deprecation cycle, so we can redefine its meaning (if we decide to).
>
> I don't see why study needs a deprecation cycle when length do
On Sun, Mar 20, 2005 at 10:54:15PM -0700, Luke Palmer wrote:
> in the same form if it does come back. So consider 6.0 its usage
> deprecation cycle, so we can redefine its meaning (if we decide to).
I don't see why study needs a deprecation cycle when length doesn't get one.
It seems fair game t
Rod Adams writes:
> Luke Palmer wrote:
> >Ummm... yeah, keep a function around if it's not currently implemented.
> >I don't think so.
> >
> I see that as preferable to saying "we had it in 5.10, we dropped it in
> 6.0, then added it back in for 6.2."
Umm... your statement isn't quite so shock
Luke Palmer wrote:
Rod Adams writes:
C is an odd sort of function. AFAIK, it's the only optimization
hint that we have.
Will the P6RE even use this information, and is it worth keeping?
My gut feeling tells me that it will be useful again around 6.2, and we
should keep it around until then as
Rod Adams writes:
> C is an odd sort of function. AFAIK, it's the only optimization
> hint that we have.
>
> Will the P6RE even use this information, and is it worth keeping?
>
> My gut feeling tells me that it will be useful again around 6.2, and we
> should keep it around until then as a pote
