Sure, another name for them are fine if you can come up with a better one. As for syntax, it's totally in line with Pikes design to use a syntax similar to C/C++/Java where the analogy is strong, which it is here.
If it wasn't obvious already, I might stress that this suggestion is completely safe when it comes to memory handling, so the paramount dangers of C/C++ pointers don't exist. Otherwise they behave in similar fashion.
As for users that judges a language only by seeing if a concept with a certain name exists in it, without bothering to learn how it works, then I think the problem is primarily in them and not in Pike. So let them go with the buzzword of the week. We only need to ensure that the manual properly explains that memory management in Pike is high level and that that of course includes pointers.
I think the situation is pretty similar to the word "string"; it's not possible to index outside strings in Pike and they don't leak etc, yet they still carry the same name as their dangerous low-level counterparts in C.
/ Martin Stjernholm, Roxen IS
Previous text:
2003-04-16 13:48: Subject: Re: Pointers/lvalues
but if they are not like c pointers they should have a different name. (and possible different syntax) the negative perception against pointers does not only exist in this crowd but amongst a lot of potential pike users who will look at pike, see "pointers", and turn away before they even had a chance to learn that these entities are really different.
and since someone brought up the similarity to c/c++ exactly because of such a similarity, same syntax expects similar/same behaviour. if the behaviour is really different, the syntax should be different too. (i am not sure in how many places pike violates this idea, but i'd like to keep it from increasing)
and because of the negative perception pointers have, the differences should be stressed here.
greetings, martin.
/ Brevbäraren