Jump to page: 1 210  
Page
Thread overview
in stinks
Mar 07, 2005
Matthew
Mar 07, 2005
Manfred Nowak
Mar 07, 2005
Matthew
Mar 07, 2005
Regan Heath
Mar 07, 2005
Matthew
Mar 07, 2005
Regan Heath
Mar 07, 2005
Matthew
Mar 07, 2005
Regan Heath
Mar 07, 2005
Ben Hinkle
Mar 07, 2005
Matthew
Mar 07, 2005
Ben Hinkle
Mar 08, 2005
Mike Parker
Mar 08, 2005
Regan Heath
Mar 08, 2005
Kris
Mar 08, 2005
Matthew
Mar 08, 2005
Kris
Mar 08, 2005
Matthew
Mar 08, 2005
Kris
Mar 08, 2005
Matthew
Mar 08, 2005
Matthew
Mar 08, 2005
Mike Parker
Mar 08, 2005
Regan Heath
Mar 08, 2005
Ben Hinkle
Mar 08, 2005
Ben Hinkle
Mar 08, 2005
Matthew
Mar 08, 2005
Ben Hinkle
Mar 08, 2005
Mike Parker
Mar 08, 2005
Regan Heath
Mar 08, 2005
Regan Heath
Mar 08, 2005
Regan Heath
Mar 10, 2005
Regan Heath
Mar 08, 2005
Matthew
Mar 08, 2005
Regan Heath
Mar 08, 2005
Matthew
Mar 08, 2005
Mike Parker
Mar 08, 2005
Mike Parker
Mar 07, 2005
Walter
Re: in stinks (opCmp)
Mar 07, 2005
John Demme
Mar 07, 2005
Brad Anderson
Mar 07, 2005
Walter
Mar 07, 2005
Ben Hinkle
Mar 07, 2005
Ben Hinkle
Mar 07, 2005
John Demme
Mar 08, 2005
xs0
Mar 08, 2005
John Demme
Mar 08, 2005
Derek Parnell
Overriding and Overloading WAS: in stinks
Mar 08, 2005
John Demme
Mar 08, 2005
Ant
Mar 08, 2005
John Demme
Mar 08, 2005
Ant
Mar 08, 2005
John Demme
Mar 09, 2005
Ant
Mar 07, 2005
brad
Mar 07, 2005
Matthew
Mar 07, 2005
Walter
Mar 12, 2005
Manfred Nowak
Mar 12, 2005
Derek Parnell
Mar 12, 2005
Manfred Nowak
Mar 12, 2005
Derek Parnell
Mar 12, 2005
jicman
Mar 07, 2005
Georg Wrede
Mar 07, 2005
Daniel Horn
Mar 07, 2005
Lionello Lunesu
Mar 07, 2005
Matthew
Mar 07, 2005
Lionello Lunesu
Mar 07, 2005
bamb00
Mar 07, 2005
Matthew
Mar 07, 2005
novice2
Mar 07, 2005
Regan Heath
Mar 07, 2005
novice2
Mar 07, 2005
Georg Wrede
Mar 07, 2005
Walter
Mar 07, 2005
Matthew
Mar 07, 2005
bamb00
Mar 08, 2005
kris
Mar 08, 2005
Regan Heath
Mar 10, 2005
Walter
Mar 07, 2005
Walter
Mar 12, 2005
Georg Wrede
March 07, 2005
Well, I know this's been savaged before, but I've not had the displeasure in using it for a long time.

Alas, I have to say AA+in stinks.

Isn't D supposed to be avoiding pointers?

How can something like the following be anything but a hideous warty piece of crap?

    Field   findField(char[] fieldName)
    in
    {
        assert(null !== fieldName);
    }
    body
    {
        Field   *pfield =   (fieldName in m_values);

        return (null === pfield) ? null : *pfield;
    }

Plus it violates KISS - it's only reasonable to do two things in one if they fit. And they clearly don't in this case.

'in' should just evaluate to true or false. And we should come up with another mechanism for testing presence *and* getting the value in one.

Ooo. How about aa having the following 'properties':

    $aa$[key]    => returns value or inserts
    .lookup(key, out value) => returns true and sets value if key in aa, otherwise returns false and leaves value as is




March 07, 2005
Matthew wrote:

> Alas, I have to say AA+in stinks.
> Isn't D supposed to be avoiding pointers?

I have this eerie feeling that "readf" will end up using pointers too ?
And with the lack of movement on the "variadic out" front, it has to...

> 'in' should just evaluate to true or false. And we should come up with another
> mechanism for testing presence *and* getting the value in one.

With the usual amount of ignorance, one can use "in" as returning bool ?
(of course, you would still have to do a second lookup to get the value)

I suggested that hash[key] should stay the h*ll away from setting keys that don't exist and just return .init, but lots of people hated it...


I think I will just continue with: (key in hash) ? hash[key] : key.init
and "optimize later". Besides, aren't hash lookup supposed to be fast ?

--anders
March 07, 2005
Matthew wrote:
> 
> How can something like the following be anything but a hideous warty piece of crap?
> 
>     Field   findField(char[] fieldName)
>     in
>     {
>         assert(null !== fieldName);
>     }
>     body
>     {
>         Field   *pfield =   (fieldName in m_values);
> 
>         return (null === pfield) ? null : *pfield;
>     }
> 
you don't understand! it's so clean when you just write it like this (just have to go back to C strings...but since we're renigging on that garbage collector and using C's malloc, why not go back to them too!)

Field   findField(char* fieldName)
/* don't need these useless things
   in
    {
        assert(null !== fieldName);
    }
    body*/
{
        return (fieldName=cast(char*)(fieldName in m_values))!=null ?
                       null:*cast(Field*)fieldName;
}

isn't it beautiful! All one statement, no tmp vars ;-)

Finally a language with all the power of C and all the ease-of-use of C, which is, in turn, a language with all the power of assembly and all the ease-of-use of assembly! The circle is now complete.


but seriously guys--this sort of ad-hoc syntacic salt has made things go a bit out of hand lately---esp that obnoxious overriding of length variables inside []--broke half my old vector code.
March 07, 2005
Am I the only one that dislikes "in" for having two completely different meanings (contracts / AA)?

Wouldn't it be 'nicer' to minimize this kind of keyword collisions by choosing them more carefully?

Yes, I know the parser understands it. When I suggested VC2005.NET's "context dependent keywords" (keywords are only keywords when they appear in the right places) a few month ago I only got replies that went something like "it results in unreadable code".

L.



March 07, 2005
While I'm with you in spirit (at least from what I'm assuming about you <g>), I don't personally agree in this specific case.

Having multiple _disjoint_ meanings for a particular word doesn't trouble me. It's when those meanings can get confused that it's troubling.



"Lionello Lunesu" <lio@lunesu.removethis.com> wrote in message news:d0h87e$21ol$1@digitaldaemon.com...
> Am I the only one that dislikes "in" for having two completely different meanings (contracts / AA)?
>
> Wouldn't it be 'nicer' to minimize this kind of keyword collisions by choosing them more carefully?
>
> Yes, I know the parser understands it. When I suggested VC2005.NET's "context dependent keywords" (keywords are only keywords when they appear in the right places) a few month ago I only got replies that went something like "it results in unreadable code".
>
> L.
>
>
> 


March 07, 2005
Lionello Lunesu wrote:

> Am I the only one that dislikes "in" for having two completely different meanings (contracts / AA)?

> Wouldn't it be 'nicer' to minimize this kind of keyword collisions by choosing them more carefully?

I think it should either be different, or a metaphore-mixing slugfest!
(as a another part of the glorious C/C++ legacy and earlier precedence)
This was why I suggested the syntax "key out hash" to remove it... :-)
Seemed to make more sense than the current recycled "delete" keyword ?

It's a general problem with D that is has a lot things built-in; but
some are so poorly implemented yet, that they make you wish that they
hadn't been - but just provided in a separate runtime library instead ?
(That might have been a bit harsh, and I do hope they all get fixed...)

--anders
March 07, 2005
Anders F Björklund <afb@algonet.se> wrote:

[...]
> I suggested that hash[key] should stay the h*ll away from setting keys that don't exist and just return .init, but lots of people hated it...
[...]

I am on your side.

However, I just believe in the psychlogical phenomenons of understanding. And one of them is, that most people once involved in a more complex piece of thinking and then understood it, just do not want to through it away, because they have invested energy into this understanding.

Most people will not accept, that the right way to reason about it, is to conclude that because of the fact that they had to invest energy, the introduction of this feature prolonges the time of learning D and that this prolonging is only justified if the costs for it are payed back in the further run.

Diminishing the costs is a major goal of the design of D. But I have never ever seen costs calculated.

-manfred

March 07, 2005
"Anders F Björklund" <afb@algonet.se> wrote in message news:d0ha1r$23hk$1@digitaldaemon.com...
> Lionello Lunesu wrote:
>
>> Am I the only one that dislikes "in" for having two completely different meanings (contracts / AA)?
>
>> Wouldn't it be 'nicer' to minimize this kind of keyword collisions by choosing them more carefully?
>
> I think it should either be different, or a metaphore-mixing slugfest! (as a another part of the glorious C/C++ legacy and earlier precedence) This was why I suggested the syntax "key out hash" to remove it... :-) Seemed to make more sense than the current recycled "delete" keyword ?

Yeah. Using delete to remove an element from the AA is an unequivocal stink. It must die.

> It's a general problem with D that is has a lot things built-in; but some are so poorly implemented yet, that they make you wish that they hadn't been - but just provided in a separate runtime library instead ? (That might have been a bit harsh, and I do hope they all get fixed...)

No, you've hit the nail on the head. Some things could be really well received, but for the way they're (currently) implemented.



March 07, 2005
Excellent philosophy.

I'd disagree with both of you that it is in any way appropriate for the [] to return a default in the case where an entry does not exist.

There are three options:

    1. return .init
    2. insert an element
    3. throw an exception

2. is what C++'s map does, which is quite a mistake (albeit one that could be ameliorated, given C++'s (current) greater expressiveness). 1. is a huge mistake, and I guess that's why no language/library (or at least none I'm aware of) has taken that option. (The exception of sorts is Ruby, which returns nil.)

IMO, 3. is the only sane solution. It's the same problem with the stinky crap of opCmp. Look at the rubbish I've had to write to get comparable Fields:

class Field
{
  . . .

/// \name Comparison
/// @{
public:
    int opCmp(Object rhs)
    {
        Field   f   =   cast(Field)(rhs);

        if(null === f)
        {
            throw new InvalidTypeException("Attempt to compare a Field with an instance of another type");
        }

        return opCmp(f);
    }
public:
    int opCmp(Field rhs)
    {
        return (this === rhs) ? 0 : std.string.cmp(m_name, rhs.m_name);
    }
/// @}


What should one do in the case where a Field is asked to compare itself against _anything_ else? Return 0? -1? +1? Assert? There's no sensible answer. The only half-sensible solution is to throw an exception, but that still stinks. What if, for some reason, someone wants to store a heterogeneous collection and do weird things with it? Frankly, I find stuff like this a f-ing joke, and it makes me truly hate D. Or, rather, it makes me resolve to never use arrays or associative arrays, and only go for DTL with its compile time type enforcement. (Of course, it's not ready yet ...)

By the way, I've an article in this month's DDJ about operator []= for C++, which discusses many of these issues, and mistakes in the C++ standard library design (which we have to hope we don't replicate in D!!).

Cheers

Matthew


"Manfred Nowak" <svv1999@hotmail.com> wrote in message news:d0ha2h$23kt$1@digitaldaemon.com...
> Anders F Björklund <afb@algonet.se> wrote:
>
> [...]
>> I suggested that hash[key] should stay the h*ll away from setting keys that don't exist and just return .init, but lots of people hated it...
> [...]
>
> I am on your side.
>
> However, I just believe in the psychlogical phenomenons of understanding. And one of them is, that most people once involved in a more complex piece of thinking and then understood it, just do not want to through it away, because they have invested energy into this understanding.
>
> Most people will not accept, that the right way to reason about it, is to conclude that because of the fact that they had to invest energy, the introduction of this feature prolonges the time of learning D and that this prolonging is only justified if the costs for it are payed back in the further run.
>
> Diminishing the costs is a major goal of the design of D. But I have never ever seen costs calculated.
>
> -manfred
> 


March 07, 2005
On Mon, 7 Mar 2005 21:49:42 +1100, Matthew <admin.hat@stlsoft.dot.org> wrote:
> There are three options:
>
>     1. return .init
>     2. insert an element
>     3. throw an exception
>
> 2. is what C++'s map does, which is quite a mistake (albeit one that could be ameliorated, given C++'s (current) greater
> expressiveness).
>
> 1. is a huge mistake, and I guess that's why no language/library (or at least none I'm aware of) has
> taken that option. (The exception of sorts is Ruby, which returns nil.)
>
> IMO, 3. is the only sane solution.

I dislike 3 also, it would require code like:

Field f;

try {
  f = array["bob"];
} catch (UnknownKeyException e) {
}

to get an item from an AA without a double lookup. Basically I worry there will be a lot of un-necessary try/catch blocks, making the code harder to read/follow.

The best soln IMO is a method call, eg.
  bool contains(KeyType key, out ValueType value);

where it returns true/false and assigns 'value' if found.

The code looks much neater:

if (array.contains("bob",f)) {
}


It can almost be done with templates, i.e. it requires implicit instantiation and the array method feature to be applied.

template contains(KeyType,ValueType) {
bool contains(ValueType[KeyType] array, KeyType key, out ValueType value) {
  ..etc..
}
}

char[char[]] array;
char[] value;

contains!(char[],char[])(array,"bob",value);


imagine the above line with implicit instantion and the array method feature...

array.contains("bob",value);

perfect!


Regan
« First   ‹ Prev
1 2 3 4 5 6 7 8 9 10