Can one overload operator_compare for Structures using a global Extends function?
Karen, that is certainly a reasonable way it could have been done, but design issues are all about tradeoffs. At the time we built this feature, something like eight years ago now, the goal was simply to provide a better mechanism for marshaling data into and out of external file formats, protocols, and libraries. If people found other useful things to do with structures, that would be fine, but it was not our goal to build a new kind of type which would be a peer to the Class - we were just trying to spare people the endless tedious calls to MemoryBlock accessors. We didn’t have to implement comparison operators in order to accomplish that goal, so we left those design problems unanswered and spent all the spent the design, development, and documentation time it would have taken elsewhere.
No.
True… but isn’t that how innovation/improvement often starts?
In that I disagree. As far as I can see, for what StringValue does, it logically has to work that way otherwise StringValue would be broken.
Hi Mars,
I know what the original intent was as I was around when structures were introduced.
But given structures generally behave like a basic datatypes and other languages support such things, I feel that this would be another step logical in the evolution of the language.
- Karen
Karen, I just tested and this is incorrect. Case won’t matter even with nil encoding.
My test code:
dim s1 as string = "this"
dim s2 as string = "THIS"
s1 = s1.DefineEncoding( nil )
s2 = s2.DefineEncoding( nil )
AddToResult s1
AddToResult s2
if s1 <> s2 then
AddToResult "not equal"
else
AddToResult "they match"
end if[quote=104432:@Kem Tekinay]Karen, I just tested and this is incorrect. Case won’t matter even with nil encoding.
[/quote]
You are right! They must be assuming ASCII…
IMO that is a bug!!!
I always thought that nil encoded strings were SUPPOSED to be treated as
a collection of meaningless bytes as there is no way to be sure what the bytes mean without an encoding.
Well I have some code to update
How are String variables stored by Xojo in memory please, including the length, encoding information and the actual data for string characters?
If there is a reference document available (from Xojo) that shows how various data types are stored in memory then please share the link.
Thanks.
There isn’t and theres unlikely to ever be one since there’s nothing you could actually do with it anyways
It is an interesting claim.
Is there a Xojo “Programmer’s Reference Manual” (not the “Language Reference”)?
Maybe the details requested above for String variable could still be shared, even if there is no reference document available and even if there is nothing that one could actually do with it anyway.
And does not the (not-a-)word “anyways” remind one of something?
Syed: to me it makes complete sense in terms of the Xojo language (hiding all the memory details for the developer). As Mars has mentioned in this thread, structures where introduced to simplify the creation of memory blocks for the following cases:
If you want to fiddle around with the memory in another way, just use MemoryBlocks. You can subclass MemoryBlock and add getters, setters and methods to create exactly what you need.
The request for String variable storage layout in memory is for reference only at this time. And there is no urgent need for its use as of now.
No
[quote=104567:@Syed Hassan]Maybe the details requested above for String variable could still be shared, even if there is no reference document available and even if there is nothing that one could actually do with it anyway.
[/quote]
It’s literally an internal implementation detail that you really cannot get at and it may vary from platform to platform
So we’re extremely unlikely to ever document the internals for users in any way as doing so would prevent / preclude us from doing anything new / different to update / revise / fix issues.