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 4870 times)

Alextp

  • Hero Member
  • *****
  • Posts: 1121
    • UVviewsoft
Re: LMath new version (LMath and Components 0.5)
« Reply #15 on: August 14, 2020, 10:50:47 am »
>So, it would really be better to prefix unit names with "LMath".

I support it.

wp

  • Hero Member
  • *****
  • Posts: 7551
Re: LMath new version (LMath and Components 0.5)
« Reply #16 on: August 14, 2020, 11:03:48 am »
I install no-design-time packages simply to let IDE know where to look for it's units.
You don't have to. I simply compile the package, I think it's even enough to just open the lpk file in the package editor. Then the unit path is known to the IDE and you can add the runtime package to the requirements of your project. FPSpreadsheet works exactly this way.

Working with runtime packages helps to keep the IDE slimmer. And it avoids the naming conflicts. But of course, I think too that a "u" prefix is not specific to identifiy the LMath units. I'd prefer an "lm" prefix for all LMath files (I hate dotted unit names...), the package should be renamed with a Pkg suffix, like lmGenMathPkg.lpk. And since these are breaking changes you should also take the opportunity to replace these ugly names: ULineAlgebra --> ULinearAlgebra or ULinAlgebra, UPolinoms --> UPolynomials. Moreover I see that the LMath directories are labeled with inconsistent casing: in some of them, the "u" is uppercase, in others it is lowercase -- this is a pain in case-sensitive OSs. CamelCase is fine with me, but please be consistent.

I could not find lmath_all.lpk in trunk.
Sorry, my fault - I had created this package by myself some time ago when I did my first tests with lmath.
Mainly Lazarus trunk / fpc 3.2.0 / all 32-bit on Win-10, but many more...

avra

  • Hero Member
  • *****
  • Posts: 2003
    • Additional info
Re: LMath new version (LMath and Components 0.5)
« Reply #17 on: August 14, 2020, 11:18:58 am »
I install no-design-time packages simply to let IDE know where to look for it's units.
You don't have to. I simply compile the package...
My bad. I used wrong wording for my actions. I also just compile and listen to IDE when it tells me not to make it fat without need.

Working with runtime packages helps to keep the IDE slimmer. And it avoids the naming conflicts.
The worse example was synapse in early days of OPM. We had synapse trunk, synapse official, and pl_synapse. All had the same named units, so when you had one project using one package, and the other project used another - you had quite a mess. That's what I try to avoid by differentiating enough lmath from dmath.

LMath directories are labeled with inconsistent casing: in some of them, the "u" is uppercase, in others it is lowercase -- this is a pain in case-sensitive OSs.
Using lower casing for all files and directories makes cross platform life of a package much easier and avoids lots of problems...
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

glorfin

  • Full Member
  • ***
  • Posts: 108
Re: LMath new version (LMath and Components 0.5)
« Reply #18 on: August 14, 2020, 11:23:19 am »
Actually, I kept names of all units inherited from DMath to maintain compatibility with DMath. "More systematic naming" in the documentation reflected change from LMath 0.4 where packages also were named uSomething to LMath 0.5 where packages became lmSomething.

So we have a question: what is better - maintain compatibility so that a project which previously used DMath can be easily switched to LMath, or make these libraries completely independent and give new names to all units.

In the latter case, I would probably also make units bigger. Jean Debord wrote a separate unit almost for every function, but now, with smart linking, it is probably not necessary and one could place related stuff in one unit to reduce uses clauses of calling programs.

To collect opinions, I created a poll in freepascal group in reddit:
https://www.reddit.com/r/freepascal/comments/i9isfp/unit_and_package_naming_in_lmath_library/


TRon

  • Hero Member
  • *****
  • Posts: 536
Re: LMath new version (LMath and Components 0.5)
« Reply #19 on: August 14, 2020, 11:31:01 am »
Actually, I kept names of all units inherited from DMath to maintain compatibility with DMath.
..
To collect opinions, ...
If the above reason is the goal then that would be a no-brainer.

Nobody in his right mind would use both at exactly the same time, and besides that, it is already possible to do so.
« Last Edit: August 14, 2020, 11:32:36 am by TRon »

glorfin

  • Full Member
  • ***
  • Posts: 108
Re: LMath new version (LMath and Components 0.5)
« Reply #20 on: August 14, 2020, 11:33:18 am »
Nobody in his right mind would use both at exactly the same time.

But one can switch from DMath to LMath, and this is easier if unit names are the same.

TRon

  • Hero Member
  • *****
  • Posts: 536
Re: LMath new version (LMath and Components 0.5)
« Reply #21 on: August 14, 2020, 11:41:19 am »
But one can switch from DMath to LMath, and this is easier if unit names are the same.
That is exactly my point. If that is your goal then you should not rename the units.

wp

  • Hero Member
  • *****
  • Posts: 7551
Re: LMath new version (LMath and Components 0.5)
« Reply #22 on: August 14, 2020, 11:58:08 am »
Why should I switch to the dead DMath in the same project once that I have decided to use the maintained LMath?

To collect opinions, I created a poll in freepascal group in reddit:
https://www.reddit.com/r/freepascal/comments/i9isfp/unit_and_package_naming_in_lmath_library/
You can create polls also here (I never created one, so I don't know why). I will not register at yet another internet site just to repeat my opinon.
« Last Edit: August 14, 2020, 01:33:22 pm by wp »
Mainly Lazarus trunk / fpc 3.2.0 / all 32-bit on Win-10, but many more...

glorfin

  • Full Member
  • ***
  • Posts: 108
Re: LMath new version (LMath and Components 0.5)
« Reply #23 on: August 14, 2020, 12:12:00 pm »
I mentioned switching from DMath to LMath, which is also easier if backwards compatibility is maintained.
(Possible reason to switch from LMath back to DMath also can exist. For example, one can find that LMath introduces too many bugs  O:-) )

And thank you, I did not notice that one can create polls here.

TRon

  • Hero Member
  • *****
  • Posts: 536
Re: LMath new version (LMath and Components 0.5)
« Reply #24 on: August 14, 2020, 12:26:57 pm »
I mentioned switching from DMath to LMath, which is also easier if backwards compatibility is maintained.
Seems I do not speak English clear enough :)

Let me try again: The suggestion in your poll to rename the units BREAKS that compatibility (*)

Last time I checked the construct alias was not available and there was no indication to add support for it nor does there seem any indication to add support for "proper" namespacing. The dotted unit-names are just a filename related implementation.

(*) which is of course perfectly fine if you wish to do so, but at the same time you are still claiming/wanting back/for -wards compatibility.
« Last Edit: August 14, 2020, 12:28:36 pm by TRon »

glorfin

  • Full Member
  • ***
  • Posts: 108
Re: LMath new version (LMath and Components 0.5)
« Reply #25 on: August 14, 2020, 12:52:18 pm »
TRon, I understand you, and agree with you. I am not inclined to rename units and break compatibility. Option 1 on the poll is exactly this one: keep names as they are. However, I am open to suggestions and want to collect opinions of other potential users.

TRon

  • Hero Member
  • *****
  • Posts: 536
Re: LMath new version (LMath and Components 0.5)
« Reply #26 on: August 14, 2020, 01:06:49 pm »
With regards to your last remark that is of course your given right as you are the maker/maintainer/developer.

The only reason I react strongly, is that I get the hunch that you started to have this opinion and put up the poll because of reasons provided by others.

Not only that, I believe the provided reasons are invalid for your project and should not concern you at all. There is a far more fundamental issue at hand there that should be addressed instead of bothering you with it.

Of course all imho.

Alextp

  • Hero Member
  • *****
  • Posts: 1121
    • UVviewsoft
Re: LMath new version (LMath and Components 0.5)
« Reply #27 on: August 14, 2020, 02:44:43 pm »
>Name units lmSomething and packages lmpkgSomething to make names unique

Need new choices:
Name units lmath.Something and (anything)
Name units lmath_Something and (anything)

TRon

  • Hero Member
  • *****
  • Posts: 536
Re: LMath new version (LMath and Components 0.5)
« Reply #28 on: August 14, 2020, 03:38:24 pm »
>Name units lmSomething and packages lmpkgSomething to make names unique

Need new choices:
Name units lmath.Something and (anything)
Name units lmath_Something and (anything)
There virtually is no choice there. The new 'namespace' addition (unit scope actually) allows for your former suggestion to (still) compile as is (provided you use the same unitnames after the dotpart that matches the original project. In case  compatibility is still wanted/required) but the latter will definitely break compatibility, see Marcov's answer here https://forum.lazarus.freepascal.org/index.php/topic,48164.msg346469.html#msg346469

However, in my opinion (as I understood the documentation) it has a flaw. You still have issues when defining two units scopes _and_ which uses the same unit names in the same project. A far better solution would imo be to have unit aliasing or package-named scopes as that shifts the burden from package/unit developer to end-user/main engine.

I find it difficult to grasp that all seem to stand or fail depending on how many packages you have installed/are in use by a project.

Alextp

  • Hero Member
  • *****
  • Posts: 1121
    • UVviewsoft
Re: LMath new version (LMath and Components 0.5)
« Reply #29 on: August 14, 2020, 03:56:11 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.

 

TinyPortal © 2005-2018