Recent

Poll

How units should be named in LMath

Keep uSomething for units and lmSomething for packages to maintain compatibility with DMath and make easier DMath -> LMath migration
2 (33.3%)
Name units lmSomething and packages lmpkgSomething to make names unique
2 (33.3%)
Rename units like in (2) and place related functions in one unit to reduce number of units
2 (33.3%)

Total Members Voted: 6

Voting closed: August 19, 2020, 12:15:58 pm

Author Topic: LMath new version (LMath and Components 0.5)  (Read 12965 times)

TRon

  • Hero Member
  • *****
  • Posts: 2398
Re: LMath new version (LMath and Components 0.5)
« Reply #30 on: August 14, 2020, 04:15:18 pm »
So I suggest the "lmath_Somthing", it breaks compatibility but for this new LMath project it's not a big problem. Apps are new.
Are you talking about the package name or the unit names ?

In case the latter, then I really do not understand why you people are taunting the developer of this package with suggesting breakable changes while he prefers to stay as compatible as possible.

If some units from his package conflicts with that of some other packages, then so be it. That is your problem as an end-user. Why keep bothering LMath developer with that is beyond me

What do you have in mind ? first come, first rights when it comes to naming units ?   >:D Even for those that would never install such a (conflicting) package ?  :'( Dot-prefixing by default does not solve it (as written earlier) but at least allows for compatibility. Underscoring would for sure break compatibility.

Have you ever considered that fpc/laz developers themselves could be adding packages that uses unit-names that then could break your suggested solution (for a moment focus on a broader area, not only this particular package) ? A said, it is a more fundamental issue that requires attention instead of suggesting workarounds that are not maintainable.

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: LMath new version (LMath and Components 0.5)
« Reply #31 on: August 14, 2020, 11:24:06 pm »
If some units from his package conflicts with that of some other packages, then so be it. That is your problem as an end-user. Why keep bothering LMath developer with that is beyond me
Try to install both dmath and lmath and you will see how your IDE reacts to having duplicated units with different content. The same as when we used to have 3 Synapse packages. If you have serious projects in dmath and want to experiment with lmath then you need both. If you didn't use dmath earlier in your projects then it is clear why my itch is not yours, too.

What you call 'bothering developer' is a normal discussion in a public forum and that has been like that at least since Roman times. We discuss topics or project we care for. He who does the work has the most power and there is no democracy in such projects, so he accepts only ideas and/or patches that do not conflict with his vision. Who does not like it is free to make a fork to follow his own vision.

Dot-prefixing by default does not solve it (as written earlier) but at least allows for compatibility. Underscoring would for sure break compatibility.
This is constructive contribution to discussion. Facts are more valued then emotions.
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: LMath new version (LMath and Components 0.5)
« Reply #32 on: August 14, 2020, 11:30:32 pm »
(4) use namespaces/dotted unit names, they are functional in 3.2.0?

wp

  • Hero Member
  • *****
  • Posts: 11830
Re: LMath new version (LMath and Components 0.5)
« Reply #33 on: August 14, 2020, 11:53:22 pm »
Try to install both dmath and lmath and you will see how your IDE reacts to having duplicated units with different content. 
Avra, again: Do not install these packages, only compile them. Then there will be not naming conflict as long as you do not use both packages in the same project (which does not make any sense at all).

I just checked it: I downloaded DMath via OPM and compiled the DMath package. Then I compiled the LMath packages (which I have on svn) and compiled one of the LMath demos. No problem at all. The IDE does know the path to these packages but loads only the one which is required by the project.

avra

  • Hero Member
  • *****
  • Posts: 2514
    • Additional info
Re: LMath new version (LMath and Components 0.5)
« Reply #34 on: August 15, 2020, 12:20:10 am »
Try to install both dmath and lmath and you will see how your IDE reacts to having duplicated units with different content. 
Avra, again: Do not install these packages, only compile them.
My bad, again.
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

TRon

  • Hero Member
  • *****
  • Posts: 2398
Re: LMath new version (LMath and Components 0.5)
« Reply #35 on: August 15, 2020, 03:07:41 am »
(4) use namespaces/dotted unit names, they are functional in 3.2.0?
They are (https://wiki.freepascal.org/FPC_New_Features_3.2.0#Support_for_Default_Namespaces) . I even got that hint from you when you posted that message I referred to  :)

But I do believe something else is dragged in at the same time as well, e.g. what to do when using multiple packages in a single project uses conflicting unit-names.

And as far as I understand it, that is still a problem.

Not with regards to DMath and LMath used at the same time, as that would make no sense, but in those cases that someone, somewhere would ever release a package that uses unit-names that someone else, somewhere else has released, and you happen to want to use both those packages inside your project at the same time.

afaik, there is currently no (easy) solution for that atm.
« Last Edit: August 15, 2020, 03:10:31 am by TRon »

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: LMath new version (LMath and Components 0.5)
« Reply #36 on: August 15, 2020, 10:39:22 am »
But I do believe something else is dragged in at the same time as well, e.g. what to do when using multiple packages in a single project uses conflicting unit-names.

The thing with dotted unit names is that if you give them both such prefixes, projects with both packages use them as is, with prefix.  Users of just one, can choose to use them, or use the default namespace parameter to trim them off.

TRon

  • Hero Member
  • *****
  • Posts: 2398
Re: LMath new version (LMath and Components 0.5)
« Reply #37 on: August 15, 2020, 04:31:17 pm »
The thing with dotted unit names is that if you give them both such prefixes, projects with both packages use them as is, with prefix.  Users of just one, can choose to use them, or use the default namespace parameter to trim them off.
The issue with that afaik is that you (as end-user) can also choose to use multiple name-space parameters so that they get  'stripped' for both packages.

But that isn't even the main problem. The end-user has no control over how someone distributes his/her package, so such package can also be released without the use of dotted unit names. So, as a hypothetical example, say package1 comes delivered with unit utypes, and package2 does as well. The project the end-user is working on requires the use of both packages and thus requires the use of both utypes units.

afaik there currently is no provision or intention to make one to be able to solve such conflict (other then renaming the units manually yourself, or provide/create a "front-end" unit for that). That you are able to specifically select either one by using the in construct is nice but seems clumsy to me as it requires the knowledge of the (installation) location for that package.

I am not saying it should act like Delphi, but there you was (still are?) able to use unit aliasing in order to solve such issues.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: LMath new version (LMath and Components 0.5)
« Reply #38 on: August 15, 2020, 05:12:41 pm »
The thing with dotted unit names is that if you give them both such prefixes, projects with both packages use them as is, with prefix.  Users of just one, can choose to use them, or use the default namespace parameter to trim them off.
The issue with that afaik is that you (as end-user) can also choose to use multiple name-space parameters so that they get  'stripped' for both packages.

Sure, but that is a third order magnitude issue. You can always pick some "weakness", but the risk of accidentally entering two specific default parameters is a small price to pay to being able to switching existing code between packages without ifdeffing or source modification, yet still use it in one project.

Quote
But that isn't even the main problem. The end-user has no control over how someone distributes his/her package, so such package can also be released without the use of dotted unit names. So, as a hypothetical example, say package1 comes delivered with unit utypes, and package2 does as well. The project the end-user is working on requires the use of both packages and thus requires the use of both utypes units.

I was more thinking about lazarus' "Online Package Manager" kind scenarios, where maintainers allow this and write the actual lpks.

Quote
afaik there currently is no provision or intention to make one to be able to solve such conflict (other then renaming the units manually yourself, or provide/create a "front-end" unit for that). That you are able to specifically select either one by using the in construct is nice but seems clumsy to me as it requires the knowledge of the (installation) location for that package.

There is no solution for that indeed, since it basically assumes "anything can happen", and package maintainers not regarding any rules.

Quote
I am not saying it should act like Delphi, but there you was (still are?) able to use unit aliasing in order to solve such issues.

That never worked well for me in the first place. Maybe because I use a lot of relative paths in my unit path, something that has been broken in Delphi (at least since BDS versions, maybe even before. Paths are relative to the IDE working directory, not to the project .dpr/dproj)

TRon

  • Hero Member
  • *****
  • Posts: 2398
Re: LMath new version (LMath and Components 0.5)
« Reply #39 on: August 15, 2020, 06:39:51 pm »
Sure, but that is a third order magnitude issue. You can always pick some "weakness", but the risk of accidentally entering two specific default parameters is a small price to pay to being able to switching existing code between packages without ifdeffing or source modification, yet still use it in one project.
Fair enough.

Please do note however that it is and was not my intention to focus on a particular weakness. It is simply something I observed, and took note off. Completely/totally ignoring it is just the another side of the spectrum  ;)

Quote
I was more thinking about lazarus' "Online Package Manager" kind scenarios, where maintainers allow this and write the actual lpks.
I am/was approaching it at a broader level. This is also an issue for fpc's package manager (which afaik OPM uses as mechanism as well).

Of course, in case you are in control then you can 'fix' some of the issues. What about those packages not being maintained (by OPM) ? There I have commercial packages in mind, for instance.

Quote
Quote
afaik there currently is no provision or intention to make one to be able to solve such conflict (other then renaming the units manually yourself, or provide/create a "front-end" unit for that). That you are able to specifically select either one by using the in construct is nice but seems clumsy to me as it requires the knowledge of the (installation) location for that package.
There is no solution for that indeed, since it basically assumes "anything can happen", and package maintainers not regarding any rules.
You could of course argue that commercial entities should not be using general used unit names, and should always be using dotted ones but is that being advertised in an official manner or are there instructions ?

As already mentioned by yourself, even the FCL itself seem to run into this issue.

Not to mention that whenever the fcl get's extended (either by using dotted names or not) that it could happen that the chosen prefix (or lack thereof) clashes with an already existing package that has been there for years (just a random example, please also see that it in a broader view e.g. lazarus packages etc)

Since everyone seems to be putting up their own package of what they believe is the right way to implement/solve certain topics there is a higher chance of such "name clashing" related issues.

Quote
Quote
I am not saying it should act like Delphi, but there you was (still are?) able to use unit aliasing in order to solve such issues.

That never worked well for me in the first place. Maybe because I use a lot of relative paths in my unit path, something that has been broken in Delphi (at least since BDS versions, maybe even before. Paths are relative to the IDE working directory, not to the project .dpr/dproj)
Yeah, I am not really fond of it either.

I understand this topic has probably been discussed a zillion of times before but my question is more if it could be solved. Should it be solved ? And in case it does, could it then be solved in such a way that it actually makes sense ?

For instance I was more thinking along the line of a "namespace" for an individual package, that could be changed at will. It does not imply an approach as used by .dot languages, rather a more direct one that allows the user to "select" a particular package by using it's namespace, preferably by allowing aliasing for them as well in case portability / compatibility is required.

Whatever the case, I thank you for the ack and feedback marcov.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11351
  • FPC developer.
Re: LMath new version (LMath and Components 0.5)
« Reply #40 on: August 15, 2020, 11:55:55 pm »
Quote
I was more thinking about lazarus' "Online Package Manager" kind scenarios, where maintainers allow this and write the actual lpks.
I am/was approaching it at a broader level. This is also an issue for fpc's package manager (which afaik OPM uses as mechanism as well).

Of course, in case you are in control then you can 'fix' some of the issues. What about those packages not being maintained (by OPM) ? There I have commercial packages in mind, for instance.

In the end, some side gives and renames. Very old and established commercial packages might force OPM managers to think twice. New commercial packages face an avoidable support problem if OPM persists because of backwards compatibility, forcing them to think twice.

Quote
Quote
There is no solution for that indeed, since it basically assumes "anything can happen", and package maintainers not regarding any rules.
You could of course argue that commercial entities should not be using general used unit names, and should always be using dotted ones but is that being advertised in an official manner or are there instructions ?

I didn't mean to suggest everything should use dotted. I suggested this for a case where there are two forks of the same package (dmath/lmath) with resulting unit clashes.

Quote
As already mentioned by yourself, even the FCL itself seem to run into this issue.

Release versions are compiled -Ur which avoids searching for source for FPC units.

But there are more such cases, e.g. both lazarus and FPC's FV unit have a "dialogs" unit.   There have been other clashes too, iirc between FV and Mac OS X specific units.

FV features hopelessly general names like drivers/editors/dialogs/time/resource/gadgets/validate/views/app.   Unfortunately it is mostly used by the most helpless of users, in the most helpless of IDEs (textmode IDE).

Quote
Not to mention that whenever the fcl get's extended (either by using dotted names or not) that it could happen that the chosen prefix (or lack thereof) clashes with an already existing package that has been there for years (just a random example, please also see that it in a broader view e.g. lazarus packages etc)

Since everyone seems to be putting up their own package of what they believe is the right way to implement/solve certain topics there is a higher chance of such "name clashing" related issues.

Well, they are still quite rare, and most resolve themselves on first realization of the conflict. And that is still the most preferable scenario, since that doesn't need continous configuration management by the user.

Quote
I understand this topic has probably been discussed a zillion of times before but my question is more if it could be solved. Should it be solved ? And in case it does, could it then be solved in such a way that it actually makes sense ?

I don't believe in a solution to end all solutions, if only because that leads to hard to maintain configuration. It only benefits the kind of people that can also workaround it other ways.

 Maybe some minor guidelines to decrease the likeliness. In time OPM also helps, since if it contains the bulk of Lazarus shared source, testing if an unitname is occupied is easier

Quote
For instance I was more thinking along the line of a "namespace" for an individual package, that could be changed at will. It does not imply an approach as used by .dot languages, rather a more direct one that allows the user to "select" a particular package by using it's namespace, preferably by allowing aliasing for them as well in case portability / compatibility is required.

If you want to make a proposal, be warned that it is not simple because the compiler rarely has an overall overview. It only searches units it needs, and programs may be compiled in multiple steps with varying parameters. (paths, default namespaces). A good understanding of how the unit system works (as in the order of processing, not the syntax) is paramount.

Pascal is halfway between C/C++ (which needs oodles of external build tools, and even then most source only meets at the linker), and Java/.NET with their carefully collections of class hierarchies, each mapped on a directory structure. (though to be honest, I don't know the real nitty, gritty rules for compilation in Java/.NET either, but I assume it is more likely to get access to all program parts at once )

Quote
Whatever the case, I thank you for the ack and feedback marcov.

No problem. The unit system always fascinated me as it is quite elegant and major component of Pascal. Some nice parts of it haven't been backported from Modula2. Maybe one day....
« Last Edit: August 15, 2020, 11:58:08 pm by marcov »

furious programming

  • Hero Member
  • *****
  • Posts: 836
Re: LMath new version (LMath and Components 0.5)
« Reply #41 on: August 16, 2020, 03:45:40 am »
Why not LMath.Something for units? Namespaces are supported and they are very useful (at least for me).

LMath as a package name seems to look good enough.
Lazarus 3.2 with FPC 3.2.2, Windows 10 — all 64-bit

Working solo on an acrade, action/adventure game in retro style (pixelart), programming the engine and shell from scratch, using Free Pascal and SDL. Release planned in 2026.

Zoran

  • Hero Member
  • *****
  • Posts: 1824
    • http://wiki.lazarus.freepascal.org/User:Zoran
Re: LMath new version (LMath and Components 0.5)
« Reply #42 on: August 16, 2020, 02:32:57 pm »
Why not LMath.Something for units? Namespaces are supported and they are very useful (at least for me).

LMath as a package name seems to look good enough.

After reading everything in this topic, this really seems to be the best option.

That would keep a fair level of compatibility (old programs just need to add -FN LMath to compile).
Still, projects which possibly have some same named units (or depend on some package which have same named units) will be able to use LMath, just have to fully qualify LMath units when adding them to uses section.

VTwin

  • Hero Member
  • *****
  • Posts: 1215
  • Former Turbo Pascal 3 user
Re: LMath new version (LMath and Components 0.5)
« Reply #43 on: August 17, 2020, 12:45:28 am »
Thanks for bring this up for discussion.

I am still learning the details of packages, but it seems to be possible to include files from multiple directories. It therefore seems that one package such as:

lmathpkg.pkg
lmath.pkg

could be used for all units currently in the LMath directory (except of course demo, and probably lmPlotter). I would love this because I currently use about 8 LMath packages in 3 projects across 3 platforms.

I support the conversion to "lmsomething.pas" for units, using lower case.



« Last Edit: August 17, 2020, 03:22:53 pm by VTwin »
“Talk is cheap. Show me the code.” -Linus Torvalds

Free Pascal Compiler 3.2.2
macOS 12.1: Lazarus 2.2.6 (64 bit Cocoa M1)
Ubuntu 18.04.3: Lazarus 2.2.6 (64 bit on VBox)
Windows 7 Pro SP1: Lazarus 2.2.6 (64 bit on VBox)

wp

  • Hero Member
  • *****
  • Posts: 11830
Re: LMath new version (LMath and Components 0.5)
« Reply #44 on: August 17, 2020, 01:05:10 am »
You must be aware that every unit cannot exist in multiple packages. glorfin provided a "summary" package lmath.lpk which requires all the other packages. Therefor you only must add lmath.lpk to the requirements of your projects to have access to all LMath units.

 

TinyPortal © 2005-2018