Greg and others said that should be avoided except for use with declares… So I asked why and got no real reasons.
I use them for custom data types that can be declared within a class (as classes can not be declared within classes in Xojo).
It’s fewer separate objects in the navigator to reduce clutter.
They can help group related properties within a class which make the class easier to read and understand… (I hate long property lists)
Using then can make autocomplete more manageable with classes with a lot properties which naturally group by use…
And all that makes coding easier and more maintainable IMO.
In general being able to group properties within a class can be useful as well as being able to write out and load a group of properties (aka Structure) as a string occasionally.
In addition, it’s likely more efficient when you need a lot of instances of the parent class as you would not have the overhead of needing to also instantiate one or more classes within each parent…
So why should structures not be used except for declares?
I don’t use them like that a lot, but when it seems appropriate, I do.
structures in Xojo are generally not as flexible as a class
you have to EXTEND them rather than add methods to them
so that kinds of break some nice encapsulation
it also mean you get NO inheritance between them
you cant declare structures in structures any more than you can declare a class in a class
you CAN nest structures much the same way you can nest classes
the structure simply declares one of its member values to be another structure type
a class simply has a property that is another class instance
in structures strings are C strings - not utf 8
they are FIXED sized strings (unlike strings in classes that are dynamic)
I’ve used them mostly for
declares
fixed sized record IO (serial or disk)
other than that I mostly opt for a class
they HAVE a use but grouping properties & such that you mention arent, IMHO, that useful or required for me to use one instead of a class
this is pretty simple to do with introspection
the only choice you need to make with classes is what to do with nested classes (do you traverse them or not to write out the entire hierarchy ?)
I was just wondering if there was an issue with using them more generally, given Greg’s declaration that they should not be used except for declares.
In some cases I find that property groups (aka structures), because they are defined in the class and don’t need to be instantiated, and help me with autocomplete, make me more productive.
As i don’t code everyday, ANYTHING that helps me not get lost in long lists in the navigator or autocomplete is really helpful for my concentration and coding productivity.
I find structures for grouping properties can be a sort of internal documentation of intent for the properties making project easier to understand when i come back to it after awhile away.
BTW I got an Email thanking me for mentioning that as they think that will help them be more productive in a project they are working on!
I just never use them that way you are/do
Thats not to say its wrong
Just that I dont find they are as useful outside of few use cases I mentioned
Personally if I find I need “groups of properties” to make my intent clear then I often reexamine the problem
Maybe a subclass would be better
Maybe an interface
Structures are not much more than memoryblocks with named positions for members
so they have no dynamic look up for anything inherited (properties, methods, etc)
So yes access to their members can be most precomputed at compile time making them faster than anything dynamic
My primary incentive for using then outside of declares is often to make the navigator more readable. I easily get lost in it to this day… My eyes get lost in long lists or a lot of text (the latter is one reason I hate API 2!)
BTW I have been known to create modules (which unfortunately have to be outside of class) just to group constants (sometimes even hierarchically!- particularly when using MBS plugins like ChartDirector ;))
I wish we could have something like structures or enums to group constants of any type!
It sounds like your project organization is the weakness there. Lifeboat is a huge, two project-file application and I know exactly where to find everything because I make use of folders, modules, and classes in a clear and organized way.
I have seen a lot of OPC projects in my time, and it seems like people really don’t put care into organization and then (unsurprisingly) can’t find anything.
I have never felt lost in the Navigator with an organized project.
Arguably, the complaints about autocomplete can be wrangled with type prefixing, but that requires a change in code style so I’m willing to call that a weakness of the way Xojo Autocomplete works.
In .NET, structs are passed by value rather than by reference. IDK if that works the same in Xojo (and Xojo’s memory management does reference counting rather than non-deterministic garbage collection anyway) but if it does, in certain situations it might be a useful performance hack to stick to the stack and avoid the heap. It would, in my view, be premature optimization to use them by default; in .NET I haven’t really had a solid use case for them as yet, but that may be an artifact of the type of apps I’m working on.
I was wondering if there was some sort of issue using them more generally… something that could cause bugs or crashes and I had just been lucky so far.
I thought Karens question was quite on point. While Structures were designed for use with Declares (at least for Xojo), they can and do have other applications. And the TOF post did infer to NEVER use them, raising the question.
FYI… Structures in other languages (Swift for example) are 1000x more useful and rarely used for “declares” (since for the most part there is no such a thing, nor are they needed)
I agree, particularly when compared to certain responses. A statement like “I’m doing everything right, that’s why everything is going great for me” isn’t particularly helpful, in my opinion. I feel that such undertones used to be less prevalent on the Xojo forums, as was the frequent self-deletion of posts. People should have the courage to stand by what they’ve written, but I digress, as now I’m also going “off-topic.”
What I miss inn that kind of statements is something like this: look, I am doing that always good, I am doing it so … description … and so… description…but no, nothing like that. Sad.
I knew what they were intended for… but that does not mean that is the only good use…
After all the xojo listbox was not intended to be able to merge cells!
When in the history of software has software NOT been used in ways not originally intended?
If a feature is coded robustly, ideally it should work as documented for any situation it is applied to, though I know that is too often not the case with Xojo, which is why I asked the question…
Why are some reading something else into my question?
