On 2008 May 7, at 4:21, TSa wrote:
BTW, what is a flack?
He's using "flak" (shrapnel; usual usage "catching flak over ...")
without understanding it.
Coming back to how C++ handles static overloading. How is
the sort order of (int *), (int &), (int), (const int *),
(const int &), (const
TSa wrote:
BTW, what is a flack?
See http://en.wikipedia.org/wiki/Flak_%28disambiguation%29
Originally, (FL)ug(a)bwehr (K)anone -- German 88mm anti-aircraft cannon
of WWII.
Subsequently, any anti-air gun or cannon, particularly when fired at a
position rather than aimed at a particular
HaloO,
John M. Dlugosz wrote:
When I mentioned this before, there was big flack over mentioning the
way C++ did it. I think that must have been miscommunicated, since I
wasn't even talking about summing all the arguments when he brought up
"Manhattan dispatch".
That he there being me, I jus
On Tue, May 06, 2008 at 08:47:47PM -0500, John M. Dlugosz wrote:
> Larry Wall larry-at-wall.org |Perl 6| wrote:
>> On Tue, May 06, 2008 at 08:20:40PM +0200, TSa wrote:
>>
>>> HaloO,
>>>
>>> John M. Dlugosz wrote:
>>>
In C++, which must be resolved at compile time, the overloading
Larry Wall larry-at-wall.org |Perl 6| wrote:
On Tue, May 06, 2008 at 08:20:40PM +0200, TSa wrote:
HaloO,
John M. Dlugosz wrote:
In C++, which must be resolved at compile time, the overloading resolution
mechanism demands that =every= parameter be at least as good of a match,
and one s
TSa Thomas.Sandlass-at-barco.com |Perl 6| wrote:
HaloO,
John M. Dlugosz wrote:
In C++, which must be resolved at compile time, the overloading
resolution mechanism demands that =every= parameter be at least as
good of a match, and one strictly better match. So the
implementation never guesse
On Tue, May 06, 2008 at 08:20:40PM +0200, TSa wrote:
> HaloO,
>
> John M. Dlugosz wrote:
>> In C++, which must be resolved at compile time, the overloading resolution
>> mechanism demands that =every= parameter be at least as good of a match,
>> and one strictly better match. So the implementati
On Tuesday 06 May 2008 10:38:38 John M. Dlugosz wrote:
> I have problems with a simple sum. The "distance" is artificially
> inflated if you make lots of small derivation steps vs one large
> change. The concept of derivation steps is ill-defined for
> parameterized types and types that change v
HaloO,
John M. Dlugosz wrote:
In C++, which must be resolved at compile time, the overloading
resolution mechanism demands that =every= parameter be at least as good
of a match, and one strictly better match. So the implementation never
guesses if worse-left/better-right is a better fit than
Mark A. Biggar mark-at-biggar.org |Perl 6| wrote:
To do multi method dispatch, you want to select the method that best
matches the parameters in the call. One way to do that is to define a
measure for distances between types and they use the method that's at
the minimum distance. One simple
HaloO,
Mark A. Biggar wrote:
To do multi method dispatch, you want to select the method that best
matches the parameters in the call.
The fundamental flaw of metric mmd is that it trades degrees of
specificity. Consider the subtype chain E <: D <: C <: B <: A
where the rule is that having an E
Carl Mäsak wrote:
John (>):
I'm still in the dark... I find an positions for "manhattan distance" but no
definition of what that is. I did find the alternative pod page earlier.
I don't have a whole answer for you, but a part that may help. What is
generally meant by "Manhattan distance" is s
John (>):
> I'm still in the dark... I find an positions for "manhattan distance" but no
> definition of what that is. I did find the alternative pod page earlier.
I don't have a whole answer for you, but a part that may help. What is
generally meant by "Manhattan distance" is so-called L1 distan
I'm still in the dark... I find an positions for "manhattan distance"
but no definition of what that is. I did find the alternative pod page
earlier.
--John
Ovid publiustemp-perl6language2-at-yahoo.com |Perl 6| wrote:
--- "John M. Dlugosz" <[EMAIL PROTECTED]> wrote:
I want to review and
--- "John M. Dlugosz" <[EMAIL PROTECTED]> wrote:
> I want to review and collect the wisdom of what has been discussed
> before. Someone mentioned this the other day, as being a significant
> consensus. But I can't find anything in the forum archives.
>
> Can someone point to the discussion, pos
15 matches
Mail list logo
