Avoid naming conflicts, please.

Targets iOS
1

Hi,

if you start or maintain a library of declares for Xojo, please make sure you prefix/postfix all your global identifiers with some tag, so we don’t get conflicts importing several things in a project.

So please put your name prefix/postfix on all class, module and interfaces names as well as global functions (including extends).

just in case we get several libraries around and want to drop them all in a project and not fix all the conflicts!

Thanks
Christian

2

Stick them all in a module so IF there is a conflict you can refer to the fully qualified name to disambiguate
ie/ str() or REALbasic.Str()

3

I just imagined that several people add with extends stuff to existing controls.

so if we get buttonTypeAT, buttonTypeMB, ButtonTypeTT or so, we have less problems.

4

[quote=160408:@Christian Schmitz]I just imagined that several people add with extends stuff to existing controls.

so if we get buttonTypeAT, buttonTypeMB, ButtonTypeTT or so, we have less problems.[/quote]

So how are the thousand methods listed in MacOSLib supposed to be updated ?

If users want to dive in declares, and furthermore mix several libraries, one can assume they are competent enough to spot eventual conflicts.

5

This does not work for classes based on WebControlWrapper for example.

6

isn’t it bad that people didn’t start marking them years ago?

7

The suggestion in the websdk docs is to use a suffix or prefix as Christian suggests.

8

It’s just not very coherent. With the introduction of the new framework you have:

  • namespaces
  • “module namespaces”
  • prefixes
  • suffixes
9

Well, even with modules and namespaces you need to mark things right.
And my fear is that if we use stuff from several libraries, there could be same thing implemented via extends to iOS controls in several libraries.

10

I was fighting that battle last night. I was trying to use Bob Keeney’s FTC and Ohanaware’s Retina kit in one project and they both declared CGRect and they were different from each other so I couldn’t just use one of them. I also had another component that had a conflict with FTC. Both had defined a graphics extension called ScaleFactor. Since I’m still using a demo of the Retina kit (so no source code yet), I had to rename FTC’s CGRect to CGRectBKS and changed the other component’s ScaleFactor to a different name. Not sure if that was the right way to do things but I was just playing around, anyway.

11

[quote=160461:@Eli Ott]It’s just not very coherent. With the introduction of the new framework you have:

  • namespaces
  • “module namespaces”
    [/quote]
    There’s no difference between these two - the only way to create a namespace is with a module
12

Oh ?
The only bug report I know of has to do with subclasses of standard controls in a module which is a different issue.

13

Just had a thought: maybe this is related to Feedback 37629 “incremental compile cache is not recognizing method scope change”. I developed the class as Global and then changed it to Public to enforce the use of the fully qualified name (Module.Class). Will test, when I will be back to my workplace.