Hey all,
Consider the following code:
class settable { private mapping data = ([]);
mixed [](string what) { if (data[what]) return data[what]; return ([])[0]; }
mixed []=(string what, mixed contents) { data[what] = contents; return contents; }
mixed ->(string what) { return [](what); }
mixed ->=(string what, mixed contents) { return []=(what, contents); } array _indices() { return indices(data); }
array _values() { return values(data); }
mixed cast(string rtype) { switch(rtype) { case "mapping": write("cast called - they want a mapping\n"); return data; default: return throw(({"Unsupported type conversion for the object", backtrace()})); } } };
int main() { object s = settable();
s["test"] = 1; s->test1 = 2; s->test2 = ([]);
write("settable: %O\n%O\n", indices(s), values(s)); m_delete((mapping)s, "test1");
return 0; }
The above program works as expected, but if I remove the explicit cast, m_delete will throw an error:
Bad argument 1 to m_delete(). Expected object with _m_delete Unknown program: m_delete(ptest()->settable(),"test1") ptest.pike:59: ptest()->main()
Which is incorrect as per the m_delete synopsis:
mixed m_delete(object|mapping map, mixed index)
Two questions I have are:
1. is there a way to define the default implicit cast for an object, so that the above code would invoke the cast() method when m_delete is called without the explicit mapping cast, or
2. is there any way to install a hook for an object to intercept index deletion in the above code (without the cast)?
TIA,
marek
If you call m_delete with an object m_delete will try to call _m_delete, as is apparent from the error message and the documentation for m_delete.
Bad argument 1 to m_delete(). Expected object with _m_delete Unknown program: m_delete(ptest()->settable(),"test1") ptest.pike:59: ptest()->main()
Which is incorrect as per the m_delete synopsis:
mixed m_delete(object|mapping map, mixed index)
No, it is not.
- is there a way to define the default implicit cast for an object,
so that the above code would invoke the cast() method when m_delete is called without the explicit mapping cast
No.
- is there any way to install a hook for an object to intercept
index deletion in the above code (without the cast)?
Yes, as stated above.
/ Martin Nilsson (Åskblod)
Previous text:
2003-02-10 19:09: Subject: Implicit vs. explicit type casting with Pike
Hey all,
Consider the following code:
class settable { private mapping data = ([]);
mixed [](string what) { if (data[what]) return data[what]; return ([])[0]; }
mixed []=(string what, mixed contents) { data[what] = contents; return contents; }
mixed ->(string what) { return [](what); }
mixed ->=(string what, mixed contents) { return []=(what, contents); } array _indices() { return indices(data); }
array _values() { return values(data); }
mixed cast(string rtype) { switch(rtype) { case "mapping": write("cast called - they want a mapping\n"); return data; default: return throw(({"Unsupported type conversion for the object", backtrace()})); } } };
int main() { object s = settable();
s["test"] = 1; s->test1 = 2; s->test2 = ([]);
write("settable: %O\n%O\n", indices(s), values(s)); m_delete((mapping)s, "test1");
return 0; }
The above program works as expected, but if I remove the explicit cast, m_delete will throw an error:
Bad argument 1 to m_delete(). Expected object with _m_delete Unknown program: m_delete(ptest()->settable(),"test1") ptest.pike:59: ptest()->main()
Which is incorrect as per the m_delete synopsis:
mixed m_delete(object|mapping map, mixed index)
Two questions I have are:
- is there a way to define the default implicit cast for an object, so that
the above code would invoke the cast() method when m_delete is called without the explicit mapping cast, or
- is there any way to install a hook for an object to intercept index
deletion in the above code (without the cast)?
TIA,
marek
/ Brevbäraren
On Mon, Feb 10, 2003 at 07:20:09PM +0100, Martin Nilsson (Åskblod) @ Pike (-) developers forum scribbled:
If you call m_delete with an object m_delete will try to call _m_delete, as is apparent from the error message and the documentation for m_delete.
Oops, missed that one :) - haven't looked at the docs carefully enough :>
Bad argument 1 to m_delete(). Expected object with _m_delete Unknown program: m_delete(ptest()->settable(),"test1") ptest.pike:59: ptest()->main()
Which is incorrect as per the m_delete synopsis:
mixed m_delete(object|mapping map, mixed index)
No, it is not.
The error message isn't consistent. The error message speaks both about m_delete() (fine) and _m_delete (not fine) - this is confusing.
- is there any way to install a hook for an object to intercept
index deletion in the above code (without the cast)?
Yes, as stated above.
thanks
marek
The error message isn't consistent. The error message speaks both about m_delete() (fine) and _m_delete (not fine) - this is confusing.
That is because it speaks both of _what_ went wrong, and _where_. This is normal, and nothing to be confused by.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-02-10 19:42: Subject: Re: Implicit vs. explicit type casting with Pike
On Mon, Feb 10, 2003 at 07:20:09PM +0100, Martin Nilsson (Åskblod) @ Pike (-) developers forum scribbled:
If you call m_delete with an object m_delete will try to call _m_delete, as is apparent from the error message and the documentation for m_delete.
Oops, missed that one :) - haven't looked at the docs carefully enough :>
Bad argument 1 to m_delete(). Expected object with _m_delete Unknown program: m_delete(ptest()->settable(),"test1") ptest.pike:59: ptest()->main()
Which is incorrect as per the m_delete synopsis:
mixed m_delete(object|mapping map, mixed index)
No, it is not.
The error message isn't consistent. The error message speaks both about m_delete() (fine) and _m_delete (not fine) - this is confusing.
- is there any way to install a hook for an object to intercept
index deletion in the above code (without the cast)?
Yes, as stated above.
thanks
marek
/ Brevbäraren
On Mon, Feb 10, 2003 at 09:10:07PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
The error message isn't consistent. The error message speaks both about m_delete() (fine) and _m_delete (not fine) - this is confusing.
That is because it speaks both of _what_ went wrong, and _where_. This is normal, and nothing to be confused by.
Right, right - if one knows where to look for and what to look for. Let's think about newbies again - given that backtrace they will most probably ask "what the hell is _m_delete? I'm not using it, I'm calling m_delete, where is _m_delete documented?" And they will hear "_m_delete() is documented in the documentation for m_delete()" - don't you think that might be a bit confusing?
marek
No, I really don't think that it will be confusing for most people.
'Illegal argument Y to X. Expected Z.' is a rather common error message. Especially in pike.
Most people will get used to it rather quickly. The alternative is not to say what the function expected. That's hardly an improvement.
/ Per Hedbor ()
Previous text:
2003-02-10 22:15: Subject: Re: Implicit vs. explicit type casting with Pike
On Mon, Feb 10, 2003 at 09:10:07PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
The error message isn't consistent. The error message speaks both about m_delete() (fine) and _m_delete (not fine) - this is confusing.
That is because it speaks both of _what_ went wrong, and _where_. This is normal, and nothing to be confused by.
Right, right - if one knows where to look for and what to look for. Let's think about newbies again - given that backtrace they will most probably ask "what the hell is _m_delete? I'm not using it, I'm calling m_delete, where is _m_delete documented?" And they will hear "_m_delete() is documented in the documentation for m_delete()" - don't you think that might be a bit confusing?
marek
/ Brevbäraren
On Mon, Feb 10, 2003 at 10:25:10PM +0100, Per Hedbor () @ Pike (-) developers forum scribbled:
No, I really don't think that it will be confusing for most people.
'Illegal argument Y to X. Expected Z.' is a rather common error message. Especially in pike.
Most people will get used to it rather quickly. The alternative is not to say what the function expected. That's hardly an improvement.
Per, note that the message is talking about TWO functions, not one.
marek
No, it's talking about an *object*, and that object is expected to have the _m_delete attribute. And it didn't, which was the error.
Quote: "Expected object with _m_delete"
This is getting boring. Do you have a better wording for that error message to suggest? Please spell it out. If not can we *please* stop this thread now?
(And I'm particularly annoyed that you can't simply say "ooops, didn't read that carefully enough, I understand now" without starting an boring discussion about how some hypothetical newbie is supposedly being confused by the error message. I've seen that and similar argument too often, and it's almost always totally irrelevant).
/ Niels Möller ()
Previous text:
2003-02-10 22:34: Subject: Re: Implicit vs. explicit type casting with Pike
On Mon, Feb 10, 2003 at 10:25:10PM +0100, Per Hedbor () @ Pike (-) developers forum scribbled:
No, I really don't think that it will be confusing for most people.
'Illegal argument Y to X. Expected Z.' is a rather common error message. Especially in pike.
Most people will get used to it rather quickly. The alternative is not to say what the function expected. That's hardly an improvement.
Per, note that the message is talking about TWO functions, not one.
marek
/ Brevbäraren
On Mon, Feb 10, 2003 at 10:45:08PM +0100, Niels Möller () @ Pike (-) developers forum scribbled:
No, it's talking about an *object*, and that object is expected to have the _m_delete attribute. And it didn't, which was the error.
Quote: "Expected object with _m_delete"
This is getting boring. Do you have a better wording for that error
yes, it is getting boring to try to get anything changed - even that simple as that.
message to suggest? Please spell it out. If not can we *please* stop this thread now?
yes, I have. Because the above is ambiguous for anybody not familiar with the guts of the code. How about
"Expected to find the _m_delete method in the passed object"
doesn't that sound a tad bit clearer? The original wording made me think until your mail that it was talking about a function called _m_delete - and I am not a newbie (maybe I'm not too bright, but people like that also write some code - most of them in visual basic, but I'm stubborn)
(And I'm particularly annoyed that you can't simply say "ooops, didn't read that carefully enough, I understand now" without starting an
I do understand only NOW. And only now I can say it.
boring discussion about how some hypothetical newbie is supposedly being confused by the error message. I've seen that and similar argument too often, and it's almost always totally irrelevant).
Nobody is forcing you to read the boring thread and, especially, to contribute to it. If you are reading the boring discussion it means nothing better to do. That's your problem, not mine. And I'm sick and tired of crappy arguments like yours above. You can start flaming now.
marek
yes, it is getting boring to try to get anything changed - even that simple as that.
This is not a forum where you get things changed. This is a forum where people does their best to find flaws in your proposed changes. That is usually a good thing, but not always.
/ Martin Nilsson (Åskblod)
Previous text:
2003-02-10 23:24: Subject: Re: Implicit vs. explicit type casting with Pike
On Mon, Feb 10, 2003 at 10:45:08PM +0100, Niels Möller () @ Pike (-) developers forum scribbled:
No, it's talking about an *object*, and that object is expected to have the _m_delete attribute. And it didn't, which was the error.
Quote: "Expected object with _m_delete"
This is getting boring. Do you have a better wording for that error
yes, it is getting boring to try to get anything changed - even that simple as that.
message to suggest? Please spell it out. If not can we *please* stop this thread now?
yes, I have. Because the above is ambiguous for anybody not familiar with the guts of the code. How about
"Expected to find the _m_delete method in the passed object"
doesn't that sound a tad bit clearer? The original wording made me think until your mail that it was talking about a function called _m_delete - and I am not a newbie (maybe I'm not too bright, but people like that also write some code - most of them in visual basic, but I'm stubborn)
(And I'm particularly annoyed that you can't simply say "ooops, didn't read that carefully enough, I understand now" without starting an
I do understand only NOW. And only now I can say it.
boring discussion about how some hypothetical newbie is supposedly being confused by the error message. I've seen that and similar argument too often, and it's almost always totally irrelevant).
Nobody is forcing you to read the boring thread and, especially, to contribute to it. If you are reading the boring discussion it means nothing better to do. That's your problem, not mine. And I'm sick and tired of crappy arguments like yours above. You can start flaming now.
marek
/ Brevbäraren
Well, people who can't read error messages written in english will obviously have a hard time with Pike, since our error messages are written in english. Removing information from the error message, so that the amount of not understood information is less, is good from some theoretical point of view, but I won't vote for it.
/ Martin Nilsson (Åskblod)
Previous text:
2003-02-10 22:15: Subject: Re: Implicit vs. explicit type casting with Pike
On Mon, Feb 10, 2003 at 09:10:07PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
The error message isn't consistent. The error message speaks both about m_delete() (fine) and _m_delete (not fine) - this is confusing.
That is because it speaks both of _what_ went wrong, and _where_. This is normal, and nothing to be confused by.
Right, right - if one knows where to look for and what to look for. Let's think about newbies again - given that backtrace they will most probably ask "what the hell is _m_delete? I'm not using it, I'm calling m_delete, where is _m_delete documented?" And they will hear "_m_delete() is documented in the documentation for m_delete()" - don't you think that might be a bit confusing?
marek
/ Brevbäraren
On Mon, Feb 10, 2003 at 10:55:08PM +0100, Martin Nilsson (Åskblod) @ Pike (-) developers forum scribbled:
Well, people who can't read error messages written in english will obviously have a hard time with Pike, since our error messages are written in english. Removing information from the error message, so that the amount of not understood information is less, is good from some theoretical point of view, but I won't vote for it.
FWIW, I have just asked an English native speaker about how does he interpret the message. The conclusion was that the _m_delete function expected an object as a parameter. So, my English my suck, but I doubt that his English sucks. But what do I know. I'm just nit-picking.
marek
On Mon, Feb 10, 2003 at 11:33:54PM +0100, Marek Habersack wrote:
FWIW, I have just asked an English native speaker about how does he interpret the message. The conclusion was that the _m_delete function expected an object as a parameter.
both interpretations are indeed possible
expected wheels with car
would usually be understood as "i expected the car to have wheels" just as:
expected car with wheels
both could also mean: "i expected the wheels to come attached to a car" but that interpreatation is less likely because here it is abvious that the main subject is the car.
for something as abstract as programming code the main subject is not at all abvious and mis interpretations are more likely.
greetings, martin.
The error message isn't consistent. The error message speaks both about m_delete() (fine) and _m_delete (not fine) - this is confusing.
I think it's quite logical,
Bad argument 1 to m_delete(). Expected object with _m_delete
^^^^^^^^^^^^^^^^^^^^^ You didn't give it an object with _m_delete. You gave it an object without _m_delete...?
/ Mirar
Previous text:
2003-02-10 19:42: Subject: Re: Implicit vs. explicit type casting with Pike
On Mon, Feb 10, 2003 at 07:20:09PM +0100, Martin Nilsson (Åskblod) @ Pike (-) developers forum scribbled:
If you call m_delete with an object m_delete will try to call _m_delete, as is apparent from the error message and the documentation for m_delete.
Oops, missed that one :) - haven't looked at the docs carefully enough :>
Bad argument 1 to m_delete(). Expected object with _m_delete Unknown program: m_delete(ptest()->settable(),"test1") ptest.pike:59: ptest()->main()
Which is incorrect as per the m_delete synopsis:
mixed m_delete(object|mapping map, mixed index)
No, it is not.
The error message isn't consistent. The error message speaks both about m_delete() (fine) and _m_delete (not fine) - this is confusing.
- is there any way to install a hook for an object to intercept
index deletion in the above code (without the cast)?
Yes, as stated above.
thanks
marek
/ Brevbäraren
On Mon, Feb 10, 2003 at 09:30:07PM +0100, Mirar @ Pike developers forum scribbled:
Bad argument 1 to m_delete(). Expected object with _m_delete
^^^^^^^^^^^^^^^^^^^^^You didn't give it an object with _m_delete. You gave it an object without _m_delete...?
I gave it object with m_delete() - and the error says that it's a bad argument to m_delete while it states that it expected an object passed to _m_delete - that is in no way logical or consistent. The first reflection is to check the correctness of the parameters passed to m_delete - they are fine, then to look for documentation of _m_delete - there is naught (save for the m_delete documentation, but the user will not look for it there since the message speaks that the error is in the parameters passed to _m_delete and http://pike.ida.liu.se/generated/manual/modref/ex/_m_delete.html is a 404). For a new user this will be mighty confusing.
marek
while it states that it expected an object passed to _m_delete
No it doesn't.
- that is in no way logical or consistent.
Nope, that's why it doesn't say that.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-02-10 22:20: Subject: Re: Implicit vs. explicit type casting with Pike
On Mon, Feb 10, 2003 at 09:30:07PM +0100, Mirar @ Pike developers forum scribbled:
Bad argument 1 to m_delete(). Expected object with _m_delete
^^^^^^^^^^^^^^^^^^^^^You didn't give it an object with _m_delete. You gave it an object without _m_delete...?
I gave it object with m_delete() - and the error says that it's a bad argument to m_delete while it states that it expected an object passed to _m_delete - that is in no way logical or consistent. The first reflection is to check the correctness of the parameters passed to m_delete - they are fine, then to look for documentation of _m_delete - there is naught (save for the m_delete documentation, but the user will not look for it there since the message speaks that the error is in the parameters passed to _m_delete and http://pike.ida.liu.se/generated/manual/modref/ex/_m_delete.html is a 404). For a new user this will be mighty confusing.
marek
/ Brevbäraren
On Mon, Feb 10, 2003 at 10:25:11PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
while it states that it expected an object passed to _m_delete
No it doesn't.
Bad argument 1 to m_delete(). Expected object with _m_delete
What does it say then?
marek
_m_delete() is to m_delete() as _indices() is to indices(). So _m_delete is the function that the object has to implement for m_delete to work on it. It doesn't matter whether it implements a function m_delete or not. Thus the missing function in the object is _m_delete. The object is passed as the first argument to m_delete. Therefore the error message in m_delete says that the object in the first argument lacks an _m_delete. It does that in a clear and concise way, imo.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-02-10 22:42: Subject: Re: Implicit vs. explicit type casting with Pike
On Mon, Feb 10, 2003 at 10:25:11PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
while it states that it expected an object passed to _m_delete
No it doesn't.
Bad argument 1 to m_delete(). Expected object with _m_delete
What does it say then?
marek
/ Brevbäraren
On Mon, Feb 10, 2003 at 11:20:06PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum scribbled:
_m_delete() is to m_delete() as _indices() is to indices(). So _m_delete is the function that the object has to implement for m_delete to work on it. It doesn't matter whether it implements a function m_delete or not. Thus the missing function in the object is _m_delete. The object is passed as the first argument to m_delete. Therefore the error message in m_delete says that the object in the first argument lacks an _m_delete. It does that in a clear and concise way, imo.
Well, I beg to differ. And it is ambiguous not only to my feeble mind. It can mean either what you said above (provided that one knows what the _indices and _values functions are for) or it may mean that the _m_delete function expects an object to be passed to it. That's the whole matter.
marek
The second interpretation is unlikely since it doesn't make sense in the given context. Before this it hasn't even occurred to me that it can be read that way. But go ahead and rephrase the message if you like.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-02-10 23:36: Subject: Re: Implicit vs. explicit type casting with Pike
On Mon, Feb 10, 2003 at 11:20:06PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum scribbled:
_m_delete() is to m_delete() as _indices() is to indices(). So _m_delete is the function that the object has to implement for m_delete to work on it. It doesn't matter whether it implements a function m_delete or not. Thus the missing function in the object is _m_delete. The object is passed as the first argument to m_delete. Therefore the error message in m_delete says that the object in the first argument lacks an _m_delete. It does that in a clear and concise way, imo.
Well, I beg to differ. And it is ambiguous not only to my feeble mind. It can mean either what you said above (provided that one knows what the _indices and _values functions are for) or it may mean that the _m_delete function expects an object to be passed to it. That's the whole matter.
marek
/ Brevbäraren
On Tue, Feb 11, 2003 at 12:35:07AM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
The second interpretation is unlikely since it doesn't make sense in the given context.
it doesn't make sense to YOU. someone who doesn't know that much about pike can't tell that.
greetings, martin.
The context is given by the first sentence, not by Pike knowledge. With the interpretation you made, the sentences have to to be unrelated.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-02-11 00:42: Subject: Re: Implicit vs. explicit type casting with Pike
On Tue, Feb 11, 2003 at 12:35:07AM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
The second interpretation is unlikely since it doesn't make sense in the given context.
it doesn't make sense to YOU. someone who doesn't know that much about pike can't tell that.
greetings, martin.
/ Brevbäraren
On Tue, Feb 11, 2003 at 12:50:09AM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum scribbled:
The context is given by the first sentence, not by Pike knowledge.
I disagree, again. This context is clear to you or anybody else on this list. It might be not for folks not as familiar with Pike as you. Sometimes one has to step down from the pedestal and look at the whole picture from a slightly different angle. After all, the documentation isn't for you - it is for people who are to learn Pike.
With the interpretation you made, the sentences have to to be unrelated.
Then how would you explain that a few people shared the interpretation? If it was only me, then I'd probably be the one to blame for the weakness of mind, but there were several voices on this forum and a few outside of it that confirmed the, in your opinion, incorrect interpretation. That's enough of a reason to state that the message is ambiguous, I think.
marek
The sentence is ambiguous. It can be fixed. Let's fix it rather than argue about it - fixing it will not make it worse in any way.
/ David Hedbor
Previous text:
2003-02-11 00:47: Subject: Re: Implicit vs. explicit type casting with Pike
The context is given by the first sentence, not by Pike knowledge. With the interpretation you made, the sentences have to to be unrelated.
/ Martin Stjernholm, Roxen IS
On Tue, Feb 11, 2003 at 12:35:07AM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum scribbled:
The second interpretation is unlikely since it doesn't make sense in
It was likely enough as to occur to several people already.
the given context. Before this it hasn't even occurred to me that it can be read that way. But go ahead and rephrase the message if you like.
You, nor any of the experienced Pike coders/developers, are not important in this case. You are biased in the sense that you know the code in and out. Don't expect that from anyone else who is trying to learn Pike. Try to look at it from the other side of the fence. I proposed two other wordings for the error in the two other messages - just let me know which suits you best and I'll add it to the CVS (and that would be a top of an iceberg only, I'm afraid...)
marek
That was a load of unsubstantiated crap. I haven't said that the error messages should be just for me. One of the interpretations here is consistent while the other means two contradicting, erroneous and/or nonapplicable sentences. If both interpretations has occurred at all it's obvious which one is intended; Pike experience is not a factor.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-02-11 00:50: Subject: Re: Implicit vs. explicit type casting with Pike
On Tue, Feb 11, 2003 at 12:35:07AM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum scribbled:
The second interpretation is unlikely since it doesn't make sense in
It was likely enough as to occur to several people already.
the given context. Before this it hasn't even occurred to me that it can be read that way. But go ahead and rephrase the message if you like.
You, nor any of the experienced Pike coders/developers, are not important in this case. You are biased in the sense that you know the code in and out. Don't expect that from anyone else who is trying to learn Pike. Try to look at it from the other side of the fence. I proposed two other wordings for the error in the two other messages - just let me know which suits you best and I'll add it to the CVS (and that would be a top of an iceberg only, I'm afraid...)
marek
/ Brevbäraren
On Tue, Feb 11, 2003 at 01:40:06AM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum scribbled:
That was a load of unsubstantiated crap. I haven't said that the error
and I didn't state that earlier. Take a deep breath or a pill and read it again. I'm merely stating that the developers are naturally biased - which is nothing wrong, it's perfectly natural. It merely means that you should ask for the opinion of people without the bias - to make the documentation better.
messages should be just for me. One of the interpretations here is
and I haven't implied that you had said that.
consistent while the other means two contradicting, erroneous and/or nonapplicable sentences. If both interpretations has occurred at all it's obvious which one is intended; Pike experience is not a factor.
It is in no way obvious. Again - it is obvious for you or people who are acquainted with Pike. Is it so hard to understand and accept? I'm not saying it is wrong - but I'm saying that neglecting to see the picture from the other side is wrong.
marek
Well, in all honesty, it is a bit unclear if thought of as a general sentence.
Expected _m_delete method in object or Expected object with _m_delete method
are more clear than
Expected object with _m_delete
which can be read as "Expected and object to be passed to the _m_delete method", although it would (also) be a very odd way to write that statement. Clarifying that an object with the _method_ _m_delete is wanted, is not a bad idea (same thing goes for other methods which would give a similar method (_indices/_values/_sprintf don't apply since they have a default behavior already and thus don't throw that particular error).
/ David Hedbor
Previous text:
2003-02-10 23:18: Subject: Re: Implicit vs. explicit type casting with Pike
_m_delete() is to m_delete() as _indices() is to indices(). So _m_delete is the function that the object has to implement for m_delete to work on it. It doesn't matter whether it implements a function m_delete or not. Thus the missing function in the object is _m_delete. The object is passed as the first argument to m_delete. Therefore the error message in m_delete says that the object in the first argument lacks an _m_delete. It does that in a clear and concise way, imo.
/ Martin Stjernholm, Roxen IS
Expected object with _m_delete method
are more clear than
Expected object with _m_delete
I'd say these sentences are fully equivalent. Taken out of context, both are equally susceptible to misinterpretation. If you interpret the second as "_m_delete should be called with an object" then there is no reason why you wouldn't interpret the first as "the _m_delete method should be called with an object".
Grendels abbreviated proposal is much better since it avoids using the "w-word" altogether, thus removing the source of the confusion.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-02-11 02:03: Subject: Re: Implicit vs. explicit type casting with Pike
Well, in all honesty, it is a bit unclear if thought of as a general sentence.
Expected _m_delete method in object or Expected object with _m_delete method
are more clear than
Expected object with _m_delete
which can be read as "Expected and object to be passed to the _m_delete method", although it would (also) be a very odd way to write that statement. Clarifying that an object with the _method_ _m_delete is wanted, is not a bad idea (same thing goes for other methods which would give a similar method (_indices/_values/_sprintf don't apply since they have a default behavior already and thus don't throw that particular error).
/ David Hedbor
What does it say then?
It says:
"Expected"
which means that the following is an account of the expected, or correct, value for the argument
"object"
which means that the value should be of type `object'
"with"
which means that the object should have some property
"_m_delete"
which means that the name of this property should be `_m_delete'.
Nowhere does it say anything about passing anything to _m_delete.
I understand that English is not your native language, but this sentence structure isn't really that complicated, is it?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-02-10 22:42: Subject: Re: Implicit vs. explicit type casting with Pike
On Mon, Feb 10, 2003 at 10:25:11PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
while it states that it expected an object passed to _m_delete
No it doesn't.
Bad argument 1 to m_delete(). Expected object with _m_delete
What does it say then?
marek
/ Brevbäraren
On Mon, 10 Feb 2003, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
What does it say then?
It says:
"Expected"
which means that the following is an account of the expected, or correct, value for the argument
"object"
which means that the value should be of type `object'
"with"
which means that the object should have some property
"_m_delete"
which means that the name of this property should be `_m_delete'.
Nowhere does it say anything about passing anything to _m_delete.
Yes the error message is not wrong but if it can be more clear, why not ? (And yes, thinking of newbies is important if you want Pike to gain acceptance).
Morever I don't think it is very good to think that poeple that want to learn Pike need to speak perfect English. Lot of poeple using Pike are not native English language poeple.
-- David Gourdelier
On Mon, Feb 10, 2003 at 11:53:53PM +0100, David Gourdelier scribbled: [snip]
which means that the object should have some property
"_m_delete"
which means that the name of this property should be `_m_delete'.
Nowhere does it say anything about passing anything to _m_delete.
Yes the error message is not wrong but if it can be more clear, why not ? (And yes, thinking of newbies is important if you want Pike to gain acceptance).
Morever I don't think it is very good to think that poeple that want to learn Pike need to speak perfect English. Lot of poeple using Pike are not native English language poeple.
Neither are those who wrote the message. But it is so damned hard to accept one's mistake (as little as it might be in this case).
marek
On Mon, Feb 10, 2003 at 11:30:07PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
What does it say then?
It says:
"Expected"
which means that the following is an account of the expected, or correct, value for the argument
thank you
"object"
which means that the value should be of type `object'
thank you
"with"
which means that the object should have some property
or that it should be used WITH the subject that follows
"_m_delete"
which means that the name of this property should be `_m_delete'.
Or that the named subject is to contain an attribute named as it preposition.
Nowhere does it say anything about passing anything to _m_delete.
In your opinion.
I understand that English is not your native language, but this sentence structure isn't really that complicated, is it?
I understand that English is not your native language, but this sentence structure isn't reall that clear, is it? Or are you saying that you know better than a native English speaker? As I said, my English may suck, but I do accept an opinion of a born English speaker - and not your opinion on the interpretation of the message.
And is it really your only weapon to nit pick on my English? Hmm? Is that the only argument you have? If yes, then I'm sorry for you. That's a low blow.
Just to nit-pick even more:
Method m_delete
mixed m_delete(object|mapping map, mixed index) Description
If map is an object that implements lfun::_m_delete() , that function will be called with index as the signle argument.
Other wise if map is a mapping the entry with index index will be removed from map destructively.
If the mapping does not have an entry with index index , nothing is done.
Why does m_delete reports an error when an object is passed? According to the above documentation, it is perfectly fine to pass an object that has no _m_delete method to that function. The word IF doesn't imply a requirement, but a possibility. In that light, the error message (the first part) is not valid according to the documentation. Change the word IF to MUST and you have just cleared up the doubt. Or is my English failing me again?
marek
According to the above documentation, it is perfectly fine to pass an object that has no _m_delete method to that function.
No, it doesn't say what happens if no _m_delete is defined. It says:
if( objectp(map) && map->_m_delete ) map->_m_delete(index); else if( mappingp(map) ) really::m_delete(map, index); else // This is never described.
Undefined behaviour usually means one of these: 1. Nothing happens (possibly returning 0 or -1 depending on situation) 2. An error is thrown. 3. Pike dumps core.
Or is my English failing me again?
It could be logic this time :)
/ Martin Nilsson (Åskblod)
Previous text:
2003-02-11 00:03: Subject: Re: Implicit vs. explicit type casting with Pike
On Mon, Feb 10, 2003 at 11:30:07PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
What does it say then?
It says:
"Expected"
which means that the following is an account of the expected, or correct, value for the argument
thank you
"object"
which means that the value should be of type `object'
thank you
"with"
which means that the object should have some property
or that it should be used WITH the subject that follows
"_m_delete"
which means that the name of this property should be `_m_delete'.
Or that the named subject is to contain an attribute named as it preposition.
Nowhere does it say anything about passing anything to _m_delete.
In your opinion.
I understand that English is not your native language, but this sentence structure isn't really that complicated, is it?
I understand that English is not your native language, but this sentence structure isn't reall that clear, is it? Or are you saying that you know better than a native English speaker? As I said, my English may suck, but I do accept an opinion of a born English speaker - and not your opinion on the interpretation of the message.
And is it really your only weapon to nit pick on my English? Hmm? Is that the only argument you have? If yes, then I'm sorry for you. That's a low blow.
Just to nit-pick even more:
Method m_delete
mixed m_delete(object|mapping map, mixed index) Description
If map is an object that implements lfun::_m_delete() , that function will be called with index as the signle argument.
Other wise if map is a mapping the entry with index index will be removed from map destructively.
If the mapping does not have an entry with index index , nothing is done.
Why does m_delete reports an error when an object is passed? According to the above documentation, it is perfectly fine to pass an object that has no _m_delete method to that function. The word IF doesn't imply a requirement, but a possibility. In that light, the error message (the first part) is not valid according to the documentation. Change the word IF to MUST and you have just cleared up the doubt. Or is my English failing me again?
marek
/ Brevbäraren
[snip]
Undefined behaviour usually means one of these:
^^^^^^^
- Nothing happens (possibly returning 0 or -1 depending on situation)
- An error is thrown.
- Pike dumps core.
There is no place for 'usually' in the programming API documentation. It's an 'either-or' situation, no 'maybe-perhaps'. The error conditions, the calling conditions, the expectations as to the parameters must be documented unambiguously and clearly. It isn't that hard to add another sentence to the documentation:
If an object does not contain the _m_delete method, an error will be thrown.
or just change the 'if' to must in the current sentence. And:
Returns The value that was removed will be returned.
Not a word about an error. Another source of uncertainty. For the record - I can change all that in the CVS, no problem, I'd be glad to do it. But I don't want to (again) step on anybody's oversensitive toes.
Or is my English failing me again?
It could be logic this time :)
I wish it was, but I'll be bold enough as to disagree :)
marek
There is no place for 'usually' in the programming API documentation.
Hey, stop doing context switches! I was talking about the documentation, not proposing an alternative wording. Not that 'usually' is forbidden in API documentation ("foobar_sort returns the bytes sorted with the glibc memcmp, usually unsigned char"), but it should obviously be avoided. There is a @throws keyword that should be used to describe when a function can throw an exception.
But there is no way we are going to see a documentation that has no undefined spots, and in those spots Pike usually behaves as I wrote...
I can change all that in the CVS, no problem, I'd be glad to do it. But I don't want to (again) step on anybody's oversensitive toes.
There is a profound difference between believing the error messages are broken (which few appearently agrees on) and that they shouldn't be fixed (which few oppose, I imagine).
/ Martin Nilsson (Åskblod)
Previous text:
2003-02-11 00:41: Subject: Re: Implicit vs. explicit type casting with Pike
[snip]
Undefined behaviour usually means one of these:
^^^^^^^
- Nothing happens (possibly returning 0 or -1 depending on situation)
- An error is thrown.
- Pike dumps core.
There is no place for 'usually' in the programming API documentation. It's an 'either-or' situation, no 'maybe-perhaps'. The error conditions, the calling conditions, the expectations as to the parameters must be documented unambiguously and clearly. It isn't that hard to add another sentence to the documentation:
If an object does not contain the _m_delete method, an error will be thrown.
or just change the 'if' to must in the current sentence. And:
Returns The value that was removed will be returned.
Not a word about an error. Another source of uncertainty. For the record - I can change all that in the CVS, no problem, I'd be glad to do it. But I don't want to (again) step on anybody's oversensitive toes.
Or is my English failing me again?
It could be logic this time :)
I wish it was, but I'll be bold enough as to disagree :)
marek
/ Brevbäraren
On Tue, Feb 11, 2003 at 01:20:06AM +0100, Martin Nilsson (Åskblod) @ Pike (-) developers forum scribbled:
There is no place for 'usually' in the programming API documentation.
Hey, stop doing context switches! I was talking about the
Hey, they are not that unrelated (I hope)!
documentation, not proposing an alternative wording. Not that
guess what, me too :)
'usually' is forbidden in API documentation ("foobar_sort returns the bytes sorted with the glibc memcmp, usually unsigned char"), but it should obviously be avoided. There is a @throws keyword that should be
glad that we agree :)
used to describe when a function can throw an exception.
But there is no way we are going to see a documentation that has no undefined spots, and in those spots Pike usually behaves as I wrote...
Sure, but that doesn't mean the documentation cannot be improved, does it? If anybody who can corrects one piece of documentation tightening the definitions, the documentation will eventually become a very good one - and that's our common goal, now isn't it?
I can change all that in the CVS, no problem, I'd be glad to do it. But I don't want to (again) step on anybody's oversensitive toes.
There is a profound difference between believing the error messages are broken (which few appearently agrees on) and that they shouldn't
Not broken - ambiguous.
be fixed (which few oppose, I imagine).
again, I'm glad that we agree.
marek
should obviously be avoided. There is a @throws keyword that should
^^^^^^^ (Though, it isn't documented in refdoc/keywords.txt... :)
Sure, but that doesn't mean the documentation cannot be improved, does it?
Somewhat more serious mode: I think you should really think deep thoughts about this past discussion and contemplate why it is this forum often explodes when you start a thread. Niels tried to prevent it from racing early on, and we all share the fault for having this heated, fun and fairly unconstructive discussion. There is no better way to trigger the reply button at smart people than implying that they are stupid (see quote above). A good start is to avoid retoric questions. They are almost only useful when you are more interested in winning a debate than convincing the opponent. Or, as my teacher in philosophy said; Who needs retoric questions?
/ Martin Nilsson (Åskblod)
Previous text:
2003-02-11 01:46: Subject: Re: Implicit vs. explicit type casting with Pike
On Tue, Feb 11, 2003 at 01:20:06AM +0100, Martin Nilsson (Åskblod) @ Pike (-) developers forum scribbled:
There is no place for 'usually' in the programming API documentation.
Hey, stop doing context switches! I was talking about the
Hey, they are not that unrelated (I hope)!
documentation, not proposing an alternative wording. Not that
guess what, me too :)
'usually' is forbidden in API documentation ("foobar_sort returns the bytes sorted with the glibc memcmp, usually unsigned char"), but it should obviously be avoided. There is a @throws keyword that should be
glad that we agree :)
used to describe when a function can throw an exception.
But there is no way we are going to see a documentation that has no undefined spots, and in those spots Pike usually behaves as I wrote...
Sure, but that doesn't mean the documentation cannot be improved, does it? If anybody who can corrects one piece of documentation tightening the definitions, the documentation will eventually become a very good one - and that's our common goal, now isn't it?
I can change all that in the CVS, no problem, I'd be glad to do it. But I don't want to (again) step on anybody's oversensitive toes.
There is a profound difference between believing the error messages are broken (which few appearently agrees on) and that they shouldn't
Not broken - ambiguous.
be fixed (which few oppose, I imagine).
again, I'm glad that we agree.
marek
/ Brevbäraren
On Tue, Feb 11, 2003 at 02:15:07AM +0100, Martin Nilsson (Åskblod) @ Pike (-) developers forum scribbled:
should obviously be avoided. There is a @throws keyword that should
^^^^^^^(Though, it isn't documented in refdoc/keywords.txt... :)
Sure, but that doesn't mean the documentation cannot be improved, does it?
Somewhat more serious mode: I think you should really think deep thoughts about this past discussion and contemplate why it is this forum often explodes when you start a thread. Niels tried to prevent it from
Martin, I do realize that I'm not being diplomatic at all. But I myself was told several times in those over 10 years on the 'Net that if you enter a public forum of people involved in software development, you should be prepared for flames and such. I know, it isn't an excuse and it is not meant to be one - the way I read it is that the only thing important is the message that is tried to be pushed on, not the wrapping. I do realize I use thought shortcuts or say things too directly or without carefully picking words, but I'm really tired of people requiring too many words to express something short and simple especially if it is said in the company of intelligent and knowledgable people. Diplomacy is fine, but it is also a waste of time.
racing early on, and we all share the fault for having this heated, fun
That's also my point above... I'd wish that it was possible to strip the words bare of emotions - especially that on forums like this (genreally, on the interenet) there are no reall emotions expressed - most of them are implied. It's our own reactions that assign emotions and emotional meaning to the words of others - it applies to all of us, probably to everyone on the 'Net.
and fairly unconstructive discussion. There is no better way to trigger
I disagree - it resulted in a cvs commit :)
the reply button at smart people than implying that they are stupid (see
I'm sorry that you preceived that, it was not my intention - and if you read my earlier messages without emotions, you will see that there was no offence intended nor contained in those messages. My (in short) statement 'the message is ambiguous and may be confusing' was meant to state just what those words mean - there was no personal context, it wasn't directed at anybody personally and yet it was perceived like so. It's probably my fault, as you say above, that I failed to employ diplomacy and wrap the meaning in round words. I'm trying to be as precise as I can in my words - that might be perceived to be rude etc. - it is not my intention, ever.
quote above). A good start is to avoid retoric questions. They are almost only useful when you are more interested in winning a debate than convincing the opponent. Or, as my teacher in philosophy said; Who needs retoric questions?
You're right on that one :) I'm sorry and I'll try to avoid unnecessary comments in the future and I do hope I cleared up my position above at least a bit.
marek
I don't think the problem has been too much frankness and brevity. But a metadiscussion is off topic so I won't go further into it, at least not in this forum.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-02-11 02:34: Subject: Re: Implicit vs. explicit type casting with Pike
On Tue, Feb 11, 2003 at 02:15:07AM +0100, Martin Nilsson (Åskblod) @ Pike (-) developers forum scribbled:
should obviously be avoided. There is a @throws keyword that should
^^^^^^^(Though, it isn't documented in refdoc/keywords.txt... :)
Sure, but that doesn't mean the documentation cannot be improved, does it?
Somewhat more serious mode: I think you should really think deep thoughts about this past discussion and contemplate why it is this forum often explodes when you start a thread. Niels tried to prevent it from
Martin, I do realize that I'm not being diplomatic at all. But I myself was told several times in those over 10 years on the 'Net that if you enter a public forum of people involved in software development, you should be prepared for flames and such. I know, it isn't an excuse and it is not meant to be one - the way I read it is that the only thing important is the message that is tried to be pushed on, not the wrapping. I do realize I use thought shortcuts or say things too directly or without carefully picking words, but I'm really tired of people requiring too many words to express something short and simple especially if it is said in the company of intelligent and knowledgable people. Diplomacy is fine, but it is also a waste of time.
racing early on, and we all share the fault for having this heated, fun
That's also my point above... I'd wish that it was possible to strip the words bare of emotions - especially that on forums like this (genreally, on the interenet) there are no reall emotions expressed - most of them are implied. It's our own reactions that assign emotions and emotional meaning to the words of others - it applies to all of us, probably to everyone on the 'Net.
and fairly unconstructive discussion. There is no better way to trigger
I disagree - it resulted in a cvs commit :)
the reply button at smart people than implying that they are stupid (see
I'm sorry that you preceived that, it was not my intention - and if you read my earlier messages without emotions, you will see that there was no offence intended nor contained in those messages. My (in short) statement 'the message is ambiguous and may be confusing' was meant to state just what those words mean - there was no personal context, it wasn't directed at anybody personally and yet it was perceived like so. It's probably my fault, as you say above, that I failed to employ diplomacy and wrap the meaning in round words. I'm trying to be as precise as I can in my words - that might be perceived to be rude etc. - it is not my intention, ever.
quote above). A good start is to avoid retoric questions. They are almost only useful when you are more interested in winning a debate than convincing the opponent. Or, as my teacher in philosophy said; Who needs retoric questions?
You're right on that one :) I'm sorry and I'll try to avoid unnecessary comments in the future and I do hope I cleared up my position above at least a bit.
marek
/ Brevbäraren
But I don't want to (again) step on anybody's oversensitive toes.
The number of oversensitive toes around here are very few. You can however expect and statements that are unclear or dissagreed on to be discussed in a heated manner.
/ Peter Bortas
Previous text:
2003-02-11 00:41: Subject: Re: Implicit vs. explicit type casting with Pike
[snip]
Undefined behaviour usually means one of these:
^^^^^^^
- Nothing happens (possibly returning 0 or -1 depending on situation)
- An error is thrown.
- Pike dumps core.
There is no place for 'usually' in the programming API documentation. It's an 'either-or' situation, no 'maybe-perhaps'. The error conditions, the calling conditions, the expectations as to the parameters must be documented unambiguously and clearly. It isn't that hard to add another sentence to the documentation:
If an object does not contain the _m_delete method, an error will be thrown.
or just change the 'if' to must in the current sentence. And:
Returns The value that was removed will be returned.
Not a word about an error. Another source of uncertainty. For the record - I can change all that in the CVS, no problem, I'd be glad to do it. But I don't want to (again) step on anybody's oversensitive toes.
Or is my English failing me again?
It could be logic this time :)
I wish it was, but I'll be bold enough as to disagree :)
marek
/ Brevbäraren
On Tue, Feb 11, 2003 at 12:35:11PM +0100, Peter Bortas @ Pike developers forum scribbled:
But I don't want to (again) step on anybody's oversensitive toes.
The number of oversensitive toes around here are very few. You can however expect and statements that are unclear or dissagreed on to be discussed in a heated manner.
That's fine and I don't mind it <humor>- but remember the saying: fight fire with fire :-)</humor>
marek
I'm explaining the intended interpretation to you, as you asked me to do. It has nothing to do with opinion, nor with weaponry.
If you want opinions, presenting alternative wordings to have options about would be a good place to start. I see you have suggested one already, my opinion on that one is that it's a bit long; do you think you could make it a bit shorter without compromising your clarity goal?
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-02-11 00:03: Subject: Re: Implicit vs. explicit type casting with Pike
On Mon, Feb 10, 2003 at 11:30:07PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
What does it say then?
It says:
"Expected"
which means that the following is an account of the expected, or correct, value for the argument
thank you
"object"
which means that the value should be of type `object'
thank you
"with"
which means that the object should have some property
or that it should be used WITH the subject that follows
"_m_delete"
which means that the name of this property should be `_m_delete'.
Or that the named subject is to contain an attribute named as it preposition.
Nowhere does it say anything about passing anything to _m_delete.
In your opinion.
I understand that English is not your native language, but this sentence structure isn't really that complicated, is it?
I understand that English is not your native language, but this sentence structure isn't reall that clear, is it? Or are you saying that you know better than a native English speaker? As I said, my English may suck, but I do accept an opinion of a born English speaker - and not your opinion on the interpretation of the message.
And is it really your only weapon to nit pick on my English? Hmm? Is that the only argument you have? If yes, then I'm sorry for you. That's a low blow.
Just to nit-pick even more:
Method m_delete
mixed m_delete(object|mapping map, mixed index) Description
If map is an object that implements lfun::_m_delete() , that function will be called with index as the signle argument.
Other wise if map is a mapping the entry with index index will be removed from map destructively.
If the mapping does not have an entry with index index , nothing is done.
Why does m_delete reports an error when an object is passed? According to the above documentation, it is perfectly fine to pass an object that has no _m_delete method to that function. The word IF doesn't imply a requirement, but a possibility. In that light, the error message (the first part) is not valid according to the documentation. Change the word IF to MUST and you have just cleared up the doubt. Or is my English failing me again?
marek
/ Brevbäraren
On Tue, Feb 11, 2003 at 12:35:06AM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
I'm explaining the intended interpretation to you, as you asked me to do. It has nothing to do with opinion, nor with weaponry.
It wasn't me who raised the flame. I appreciate your explanation and I took the liberty to oppose it to mine. Which is equally as valid as yours - that proved the message is ambiguous.
If you want opinions, presenting alternative wordings to have options about would be a good place to start. I see you have suggested one already, my opinion on that one is that it's a bit long; do you think you could make it a bit shorter without compromising your clarity goal?
I think so. Let's try this:
Bad parameter... bla bla. Expected an object containing the _m_delete method.
perhaps use 'implementing' instead of 'containing'.
marek
It wasn't me who raised the flame.
Thus no flame has been risen, has it?
I appreciate your explanation and I took the liberty to oppose it to mine. Which is equally as valid as yours
Not valid in the sense of being the correct interpretation of the text though.
Bad parameter... bla bla. Expected an object containing the _m_delete method.
perhaps use 'implementing' instead of 'containing'.
Sounds ok. Perhaps the "an" can be dropped, it's usually left out for brevity since it doesn't add any information.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-02-11 00:45: Subject: Re: Implicit vs. explicit type casting with Pike
On Tue, Feb 11, 2003 at 12:35:06AM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
I'm explaining the intended interpretation to you, as you asked me to do. It has nothing to do with opinion, nor with weaponry.
It wasn't me who raised the flame. I appreciate your explanation and I took the liberty to oppose it to mine. Which is equally as valid as yours - that proved the message is ambiguous.
If you want opinions, presenting alternative wordings to have options about would be a good place to start. I see you have suggested one already, my opinion on that one is that it's a bit long; do you think you could make it a bit shorter without compromising your clarity goal?
I think so. Let's try this:
Bad parameter... bla bla. Expected an object containing the _m_delete method.
perhaps use 'implementing' instead of 'containing'.
marek
/ Brevbäraren
On Tue, Feb 11, 2003 at 01:00:06AM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
Thus no flame has been risen, has it?
well, somebody at #caudium said the word :)
I appreciate your explanation and I took the liberty to oppose it to mine. Which is equally as valid as yours
Not valid in the sense of being the correct interpretation of the text though.
This is the point - there should be no room for interpretation there, it should be precise and clear without any margin for ambiguity.
Bad parameter... bla bla. Expected an object containing the _m_delete method.
perhaps use 'implementing' instead of 'containing'.
Sounds ok. Perhaps the "an" can be dropped, it's usually left out for brevity since it doesn't add any information.
ok, that's fine. In CVS now. Looks much better now :> :)
marek
I gave it object with m_delete() - and the error says that it's a bad argument to m_delete while it states that it expected an object passed to _m_delete
No, not passed. It doesn't say anything about how it expects _m_delete to behave, only about what m_delete expects:
The first argument to m_delete is either a mapping or an object, but the object must be of a class that has an _m_delete method, "object with _m_delete".
How would you phrase it so it's more clear?
/ Mirar
Previous text:
2003-02-10 22:20: Subject: Re: Implicit vs. explicit type casting with Pike
On Mon, Feb 10, 2003 at 09:30:07PM +0100, Mirar @ Pike developers forum scribbled:
Bad argument 1 to m_delete(). Expected object with _m_delete
^^^^^^^^^^^^^^^^^^^^^You didn't give it an object with _m_delete. You gave it an object without _m_delete...?
I gave it object with m_delete() - and the error says that it's a bad argument to m_delete while it states that it expected an object passed to _m_delete - that is in no way logical or consistent. The first reflection is to check the correctness of the parameters passed to m_delete - they are fine, then to look for documentation of _m_delete - there is naught (save for the m_delete documentation, but the user will not look for it there since the message speaks that the error is in the parameters passed to _m_delete and http://pike.ida.liu.se/generated/manual/modref/ex/_m_delete.html is a 404). For a new user this will be mighty confusing.
marek
/ Brevbäraren
On Mon, Feb 10, 2003 at 11:50:06PM +0100, Mirar @ Pike developers forum scribbled:
I gave it object with m_delete() - and the error says that it's a bad argument to m_delete while it states that it expected an object passed to _m_delete
No, not passed. It doesn't say anything about how it expects _m_delete to behave, only about what m_delete expects:
The first argument to m_delete is either a mapping or an object, but the object must be of a class that has an _m_delete method,
The documentation doesn't say it must contain the method.
"object with _m_delete".
How would you phrase it so it's more clear?
It is clear to you. And already several people stated that they see the ambiguity - people with much less experience than you. If you think that whatever is clearly understood to a person that knows some subject in and out must be as clear to any newcomer or even a person with a little less experience, then you're wrong. The art of writing good documentation and giving good error messages is when both of those items are understood to those who need the documentation for learning - for less experienced or new users of the language. And any documentation of an API must not contain any ambiguities. Like the phrase in the m_delete() docs which contains IF instead of MUST - that's an ambiguity and it should not happen in this instance.
marek
I know this isn't what you asked, but
return throw(({"Unsupported type conversion for the object", backtrace()}));
is much simpler written as
| error("Unsupported type conversion for the object");
if I didn't misunderstand something here...
/ Mirar
Previous text:
2003-02-10 19:09: Subject: Implicit vs. explicit type casting with Pike
Hey all,
Consider the following code:
class settable { private mapping data = ([]);
mixed [](string what) { if (data[what]) return data[what]; return ([])[0]; }
mixed []=(string what, mixed contents) { data[what] = contents; return contents; }
mixed ->(string what) { return [](what); }
mixed ->=(string what, mixed contents) { return []=(what, contents); } array _indices() { return indices(data); }
array _values() { return values(data); }
mixed cast(string rtype) { switch(rtype) { case "mapping": write("cast called - they want a mapping\n"); return data; default: return throw(({"Unsupported type conversion for the object", backtrace()})); } } };
int main() { object s = settable();
s["test"] = 1; s->test1 = 2; s->test2 = ([]);
write("settable: %O\n%O\n", indices(s), values(s)); m_delete((mapping)s, "test1");
return 0; }
The above program works as expected, but if I remove the explicit cast, m_delete will throw an error:
Bad argument 1 to m_delete(). Expected object with _m_delete Unknown program: m_delete(ptest()->settable(),"test1") ptest.pike:59: ptest()->main()
Which is incorrect as per the m_delete synopsis:
mixed m_delete(object|mapping map, mixed index)
Two questions I have are:
- is there a way to define the default implicit cast for an object, so that
the above code would invoke the cast() method when m_delete is called without the explicit mapping cast, or
- is there any way to install a hook for an object to intercept index
deletion in the above code (without the cast)?
TIA,
marek
/ Brevbäraren
([])[0] is much clearer written as UNDEFINED.
Aliasing like
mixed `->(string what) { return `[](what); }
is better written as
constant `->=`[];
/ Martin Nilsson (Åskblod)
Previous text:
2003-02-10 19:30: Subject: Implicit vs. explicit type casting with Pike
I know this isn't what you asked, but
return throw(({"Unsupported type conversion for the object", backtrace()}));is much simpler written as
| error("Unsupported type conversion for the object");
if I didn't misunderstand something here...
/ Mirar
constant `->=`[];
You can do that now? Excellent. Earlier, functions were considered anti-constant...
/ Mirar
Previous text:
2003-02-10 19:36: Subject: Implicit vs. explicit type casting with Pike
([])[0] is much clearer written as UNDEFINED.
Aliasing like
mixed `->(string what) { return `[](what); }
is better written as
constant `->=`[];
/ Martin Nilsson (Åskblod)
It doesn't, since it's a syntax error. The following will work better:
function `-> =`[];
(And soon it will work even better in a Pike 7.5).
/ Henrik Grubbström (Lysator)
Previous text:
2003-02-10 20:20: Subject: Implicit vs. explicit type casting with Pike
function `->=`[]; works though...
/ Martin Nilsson (Åskblod)
Yep, references from an object to itself or to a function in it are no longer counted in 7.5.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-02-10 21:04: Subject: Implicit vs. explicit type casting with Pike
It doesn't, since it's a syntax error. The following will work better:
function `-> =`[];
(And soon it will work even better in a Pike 7.5).
/ Henrik Grubbström (Lysator)
On Mon, Feb 10, 2003 at 09:05:09PM +0100, Henrik Grubbström (Lysator) @ Pike (-) developers forum scribbled:
It doesn't, since it's a syntax error. The following will work better:
function `-> =`[];
(And soon it will work even better in a Pike 7.5).
Speaking of constructs - is there any fairly up to date BNF for the current Pikes...?
marek
Yes, it's called "language.yacc". ;-)
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2003-02-10 22:11: Subject: Re: Implicit vs. explicit type casting with Pike
On Mon, Feb 10, 2003 at 09:05:09PM +0100, Henrik Grubbström (Lysator) @ Pike (-) developers forum scribbled:
It doesn't, since it's a syntax error. The following will work better:
function `-> =`[];
(And soon it will work even better in a Pike 7.5).
Speaking of constructs - is there any fairly up to date BNF for the current Pikes...?
marek
/ Brevbäraren
On Mon, Feb 10, 2003 at 10:15:10PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum scribbled:
Yes, it's called "language.yacc". ;-)
It is a mess, a royal mess :) :) How am I supposed to write a pike parser based on that without sitting on it 8h/day for 4 months? :)
marek
And
mixed [](string what) { if (data[what]) return data[what]; return ([])[0]; }
can be shortened to
mixed [](string what) { return data[what]; }
(Unless it's a deliberate feature that a value of zero is returned as UNDEFINED.)
/ Martin Stjernholm, Roxen IS
Previous text:
2003-02-10 19:36: Subject: Implicit vs. explicit type casting with Pike
([])[0] is much clearer written as UNDEFINED.
Aliasing like
mixed `->(string what) { return `[](what); }
is better written as
constant `->=`[];
/ Martin Nilsson (Åskblod)
On Mon, Feb 10, 2003 at 08:05:10PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum scribbled:
And
mixed [](string what) { if (data[what])return data[what]; return ([])[0]; }
can be shortened to
mixed [](string what) { return data[what]; }(Unless it's a deliberate feature that a value of zero is returned as UNDEFINED.)
That was the intention, yes.
marek
pike-devel@lists.lysator.liu.se
-
David Gourdelier -
David Hedbor ＠ Pike developers forum -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Marek Habersack -
Martin Baehr -
Martin Nilsson (�skblod) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Niels M�ller () ＠ Pike (-) developers forum
-
Per Hedbor () ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum