My attempt to use FAT

[LGR]

Since the standard FAT libraries are acting strangely, I thought I'd try Dany's Fat32 lib. I got this far:

fat32.jpg (109.7 KiB) Viewed 15327 times

Did I do anything wrong, or is this not quite ready?

[Dany]

Hi, I see that the first error is

Identifier "Part" has been already declared in "__Lib_mmc_Fat16_Defs.mpas"

Can it be the case that in your project the mmc_Fat16 lib is still included (or some parts of it)?

[LGR]

Yes. It isn't obvious that I have to scrub all the standard MMC_FAT libraries out.

I think I'll start a clean project with this, and see what happens.

[LGR]

I created a new project, and got the same thing. What appears to be happening is that variables in this library conflict with variables in other libraries. When you turn all libraries off except the ones you need, the problem goes away. I can see that this is going to be a problem as Libstock proliferates. It's going to mean that certain libraries will be incompatible with others, and you won't be able to use both in a program.

[VCC]

When you turn all libraries off except the ones you need, the problem goes away. I can see that this is going to be a problem as Libstock proliferates. It's going to mean that certain libraries will be incompatible with others, and you won't be able to use both in a program.

It's time for mikroElektronika to allow two routines with the same name, from different libraries to be compiled in the same project. This would solve many problems. However, this would make the compiler more Delphi like.

[janni]

What appears to be happening is that variables in this library conflict with variables in other libraries. When you turn all libraries off except the ones you need, the problem goes away. I can see that this is going to be a problem as Libstock proliferates. It's going to mean that certain libraries will be incompatible with others, and you won't be able to use both in a program.

Well, mutually exclusive libs may in principle have same variable/procedure/function names. One hardly expects them both included in one project.
On the other hand, it's certainly good practice to use unique names in libraries and Libstock may need a page dedicated to some instructions for library developers.

It's time for mikroElektronika to allow two routines with the same name, from different libraries to be compiled in the same project.

Maybe I'm wrong, but, excluding overloading, something like that may be possible only in object oriented language. (Not that I would mind procedure/function overloading in mP .)

[LGR]

The problem is, they weren't necessarily mutually exclusive libraries, and the conflicts weren't all over procedures. One of the conflicts was over a variable named "Max", and it wasn't in the FAT package, it was in the dependent package "StrngUtils". When we start building libraries upon dependent libraries, the possibility for conflicts goes up dramatically, because you're forced to use several libraries.

This is a really stupid question, but wasn't the Package Manager supposed to handle compiled modules without source code, so these kinds of conflicts won't matter?

[janni]

Whether source code is available or not, rules are the same - compiler has no way to choose between identically named variables or routines, so it has to indicate conflict.

[LGR]

If it's a compiled object file, the internal variable and procedure names don't need to exist anymore. The only things that need to remain are the names of the library procedures.

Let me put it another way - if the linker is using procedure names, and more than one procedure of that name is available, they probably need to generate a meta-identifier with the library name in it to distinguish between the two. You'll end up with something like directory names.

How do open-source developers of large projects handle this issue? Without pre-coordination, this problem is bound to surface.

[VCC]

compiler has no way to choose between identically named variables or routines, so it has to indicate conflict.

There is a way. If you have somewhere in a unit (e.g. MyUnit) something like:

Code: Select all

Uses Unit1, Unit2;

and both Unit1 and Unit2 export a routine, let's say, MyProc. If you call MyProc within MyUnit, the compiler should consider the first one, that is the MyProc from Unit1 because it is written first in the uses clause. To call the MyProc from Unit2, the user should call it

Code: Select all

Unit2.MyProc;

However,

Code: Select all

Unit1.MyProc;

should also be available for MyProc from the Unit1. There would be no conflicts with this approach. Same for variables and constants.

[janni]

Let me put it another way - if the linker is using procedure names, and more than one procedure of that name is available, they probably need to generate a meta-identifier with the library name in it to distinguish between the two. You'll end up with something like directory names.

It's not internal naming that's a problem here - without additional rules compiler simply has no way to guess programmers intentions.

How do open-source developers of large projects handle this issue?

Mostly using unique names . Common rule is to use library name (unit name, or any other name reflecting the task performed) as a prefix or part of name. Naturally only public (global) types/routines/variables/objects need unique names.

There is a way. If you have somewhere in a unit (e.g. MyUnit) something like:

Code: Select all

Uses Unit1, Unit2;

and both Unit1 and Unit2 export a routine, let's say, MyProc. If you call MyProc within MyUnit, the compiler should consider the first one, that is the MyProc from Unit1 because it is written first in the uses clause. To call the MyProc from Unit2, the user should call it

Code: Select all

Unit2.MyProc;

Yes, indeed, I've forgotten about similar solution in Delphi. Still, this may be a solution for compiler developers, but I'm not sure it's good for programmers. Just too easy to make mistakes.

It must have always seemed a bad programming practice to me as I do not recall ever (conciously ) using such possibility with Delphi (after all it's not so hard to use unique names). To make things more ambiguous, while in Delphi the last unit from the list is regarded default, routines from initialisation sections are executed in order of units' appearance in the uses clause .

[janni]

Few late thoughts .

If there'll be enough requests from users, mE developers may introduce a mechanism that will discern between identically named variables/routines/types from different units and let compiler choose automatically one over the others. But what then?

Lets imagine two not-so-well-documented (a norm, I'm afraid) libraries used together. How will the user of these know that there was a conflict and which routine is actually executed, or which global variable used? Probably only while painstakingly debugging wrongly behaving code .

I do not think that the problem highlighted by LGR may be solved in any other way than by educating those from us that write libraries. I'm certain that most of those will gladly correct their libs when asked to, but it would be easier to give them some guidelines and what better place for these as Libstock?

[LGR]

If there'll be enough requests from users, mE developers may introduce a mechanism that will discern between identically named variables/routines/types from different units and let compiler choose automatically one over the others. But what then?

It might be possible for the compiler to search all libraries and point out multiple instances, which is better than what happens now. But then the user is still at a loss for what to do, especially when the conflict is between dependent libraries, and the user isn't even aware of the dependencies.

Maybe a better idea would be for Package Manager to be in contact over the internet with an mE global identifier database, and won't let the developer create a package if some other registered package has already claimed it. Identifiers would be allowed on a "first come, first serve" basis.

[VCC]

Lets imagine two not-so-well-documented (a norm, I'm afraid) libraries used together. How will the user of these know that there was a conflict and which routine is actually executed, or which global variable used?

It might be possible for the compiler to search all libraries and point out multiple instances, which is better than what happens now.

Yes, the compiler should point out that there are conflicts, but should not treat them as such. It should only constrain the user to choose a particular routine like Unit1.MyProc or Unit2.MyProc and not simply MyProc as I said in my previous post.

[janni]

This would cover only a part of the problem . Identical identifiers conflict, like in the case spotted by LGR, may concern dissimilar objects - moreover, these identifiers may be inaccessible from outside of a library. I'm afraid that care in choosing unique names cannot be replaced by a set of smart rules for compiler.