[fpc-pascal] stuck with untyped pointer

[spir ☣]

On Sat, 29 May 2010 00:33:00 +0200
José Mejuto <joshyfun at gmail.com> wrote:

> s> But the object layer brings the biggest issue with the implicit
> s> "self" causing names external to a method to clash with local
> s> names.  
> 
> Hmmm... I think that this should not happend. Is the case in your
> posted example ?

I mean when (how do you call this in Pascal: attributes?), say, fields and/or method names conflict with simple (usually local) variable names. This only happens because fields/methods can be denoted implicitely. So, the compiler may relate a name "value" to a "value" slot of the class of the current target; while the for the programmer "value" is a local var. And the value slot has nothing to do here -- but the compiler cannot know it.
I find this wrong. Well, just my point of view. This design choice causes namespaces to leak ;-) In any other case, a locally introduced name acts like if were prefixed eg "local.value": private to the current namespace and thus totally safe. Object pascal's design choice makes field/method names also belong to every local namespace!

> s> Worse: the compiler _sometimes_ blocks when var names conflict with
> s> slot names (I have not yet understood when/why it does or not).
> s> No offense intended, but I consider this as a language-design
> s> error. (symptom: lexical paralysis ; cause: namespace leak)  
> 
> Var names "slot" names ? Which is a "slot name" ? Can you post a brief
> example ?

Sorry, I'm using terminology imported form another paradigm: "slot" is a general word for either data (property) or executable (method) field of a given object. Rather used in the prototype-based community. (A very practicle word because unambiguous; even "attribute" is sometimes unclear, may denote only data slots for some people, or only public ones. Slot only and always means "any kind of element belonging to an object".)


Denis
________________________________

vit esse estrany ☣

spir.wikidot.com