FreeBASIC 1.08 Development

For other topics related to the FreeBASIC project or its community.
MrSwiss
Posts: 3303
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: FreeBASIC 1.08 Development

Postby MrSwiss » Nov 10, 2019 22:35

MrSwiss wrote:Anyhow, separately compiled isn't the same as include-file (point at issue, right now!).
Lost Zergling
Posts: 257
Joined: Dec 02, 2011 22:51
Location: France

Re: FreeBASIC 1.08 Development

Postby Lost Zergling » Nov 10, 2019 22:50

I think fxm's solution shall be seen as strictly technical meaning not conceptual nor standing for or against JK proposal. I just see it as a technical opening. @Mr Swiss : indeed I agree your point of view about implementation.
Juergen Kuehlwein
Posts: 262
Joined: Mar 07, 2018 13:59
Location: Germany

Re: FreeBASIC 1.08 Development

Postby Juergen Kuehlwein » Nov 11, 2019 9:53

Why is this so hard to understand?

- MrSwiss posted code, which indeed works. It makes use of overloaded procedures, which are setup by default for the default variable type. For UDTs you must setup an appropriate function, before you can use it. A macro is supplied for this task. So far so good.

- my reply was, that all of this is possible without the need for a macro call. I already have developped similar (much more comprehensive) array extensions, which can do the same without the need for a setup macro by the user. Among other things it offers a dedicated function for retrieving each member of the array descriptor separately.

- MrSwiss replied, that my method would require 7 calls to get the full descriptor information (implying that his method is required to do that).

- I posted code, which shows a (already existing) method of retrieving the array descriptor of array of any kind (including UDTs). The decisive line is (using fbc):

Code: Select all

  Dim As FBARRAY Ptr pa = ArrayDescriptorPtr(array())

or (with namespace prefix)

Code: Select all

  Dim As FBC.FBARRAY Ptr pa = FBC.ArrayDescriptorPtr(array())

this code doesn´t need a setup macro for UDTs. It´s one single line and it works everwhere.

If you look at the declaration of ArrayDescriptorPtr in fbc-init\array.bi you will notice, that the array is declared "AS ANY", which doesn´t work for regular FB code (that is, as fxm, showed, it is possible, but only under certain circumstances). The RTL can accept arrays "AS ANY". Never wondered how RTL functions for arrays like UBOUND work - for all kinds of arrays?


So while MrSwiss´code works, there is an easier method.
MrSwiss
Posts: 3303
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: FreeBASIC 1.08 Development

Postby MrSwiss » Nov 11, 2019 15:17

Juergen Kuehlwein wrote:I already have developped similar (much more comprehensive) array ...
That others would likely call: BLOAT. (JK seems to only want "his own stuff", using any means
preferably without competition, see below for explanation)
Juergen Kuehlwein wrote:- MrSwiss replied, that my method would require 7 calls to get the full descriptor information (implying that his method is required to do that).
Red part is a straight lie: because I've clearly stated that my method does it "all in one".
(Proof required? Just a single Sub retrieves all the header information.)
Your methods require 7 calls (one argument per call), mine does it "single-shot", all at once.

The remainder of the post is nothing but common knowledge ...
(The code is most likely just a "copy & paste" from my code. Seem to remember: pa)
Juergen Kuehlwein
Posts: 262
Joined: Mar 07, 2018 13:59
Location: Germany

Re: FreeBASIC 1.08 Development

Postby Juergen Kuehlwein » Nov 11, 2019 16:41

Sigh... i repeat what i already said above: why is this so hard to understand, that only one single line and nothing else is required to retrieve all information (=all in one) in an array´s descriptor? You don´t need a separate overloaded function for each type of array in this case.

Code: Select all

Dim As FBC.FBARRAY Ptr pa = FBC.ArrayDescriptorPtr(array())


This is my last post to this topic.
fxm
Posts: 9250
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: FreeBASIC 1.08 Development

Postby fxm » Nov 11, 2019 17:01

I obviously agree.
That's how I use it already, and I'll use it later too.
(the simplest and the fastest)
MrSwiss
Posts: 3303
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: FreeBASIC 1.08 Development

Postby MrSwiss » Nov 11, 2019 17:08

Obviously "other peoples arguments" don't seem to count at all.
Juergen Kuehlwein wrote:You don´t need a separate overloaded function for each type of array in this case.
You're right (I don't need it) but also wrong, most users demand "ease of use" and,
that is what it's all about (as Lost Zergling confirmed, in the post made).
Lost Zergling
Posts: 257
Joined: Dec 02, 2011 22:51
Location: France

Re: FreeBASIC 1.08 Development

Postby Lost Zergling » Nov 11, 2019 18:13

I m just watching around the ideas. Considering the idea seeing the preprocessor as an object. Considering the idea the linker could be seen as a conceptual layer in its own rights... I see these as possibilities. My idea the linker layer outside the Fb core, nevertheless inside the ecosystem.
Lost Zergling
Posts: 257
Joined: Dec 02, 2011 22:51
Location: France

Re: FreeBASIC 1.08 Development

Postby Lost Zergling » Nov 12, 2019 10:10

I think it might be possible to implement a specific prefix for features that use preprocessor specifications, which from the user's point of view could be manipulated a bit like a global object (pp_ARRAY, pp_VIDEO, and so on, a syntax close to pp.ARRAY, and so on). This would perhaps bring a dimension of ease to the use of the preprocessor : a conceptual standardization in phase with the technical framework. Regarding the question of the conceptual implementation of a module with separate compilation but still the same language, the user must be able to understand ergonomically if the language is strongly typed or not (and when?). There is a paradox here: to be both static and dynamically typed, a little like wanting to go beyond the framework of object design whereas almost everything can be programmed in object design. So I see automatic or dynamic typing as a conceptual "vertical" scope, and going down to the technical side, I'll see something like this:
VerticalScope UniversalTypes' All Types Ptr inherit from calling procedure
...
End VerticalScope
Thus, the ways of the ecosystem and as they provide technical openings, are intended to find a conceptual outlet. It's a kind of "inverted" way to see things evolve, but I'm just pragmatic in trying to translate and make a connection with the "hight level" in terms of implementation. From the "design" point of view, the "new eye" side is what I can bring, and so what I do not know is as important to me as what I already know, because once we know, we have fewer ideas to reinvent things, so I have to try to "know less" as long as possible, and compel myself to conceptualize. This to clarify my approach. My wish is not to say if this or that code is better than another, but to deepen the side "box ideas", open minded, knowing that it is not my role to program that and I m not even considering trying.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 3 guests