Structs and Classes
These are extended user defined types, with named access to individual fields and additional typechecking.
There are actually four different types of structures:
All four are reference types: each instance must be created via new(), and if saved in more than one place, modifying any modifies all such copies/references.
In particular you should note that the result from new() is not normally suitable for passing to repeat(), similar to allocate() I suppose, and instead you should typically invoke new() n times to populate a sequence of length n. Obviously however a single new() can suffice in a repeat(dummy,n) style scenario, whereby you shouldn’t be modifying any of them that haven’t been replaced anyway, and hence don’t care that modifying one of them modifies the rest. The original design also had a sequence-based type, with copy-on-write semantics, however it proved much more difficult to implement, and besides any benefits that might have bought are probably much better obtained via the traditional myseq[MYENUM] style syntax anyway. Another way of saying that might be: Why would you bother to introduce a entirely brand new type system and syntax if it is not radically different to whatever you already have?
Some performance has been sacrificed in the name of programmer productivity, simplifying and managing complexity, enhancing and enforcing type checking, and being flexible enough to cater for as many forseeable needs as possible. That is largely true of any similar system, including object orientated ones, admittedly [at this time] probably more pronounced in Phix than say C++/Go. Not a problem for several hundred or even thousand structs/objects, however (for instance) a standard phix sequence holding 4096 x 2160 pixels will seriously outperform invoking new() more than 8 million times, and not necessarily just during initialisation. Obviously, should benefits such as improved code clarity fail to outweigh a significant performance hit, then in that specific case structs/classes are quite simply entirely inappropriate and should not be used.
Also note that structs/classes are not directly comparable: you cannot use sort() on sequences of structs/classes, instead it would have to be a custom_sort(), or even better yet use a class rather than a sequence to contain not only the list of structs/classes but also the internal/private method(s) needed to compare and sort them.
Likewise, although such operations may still be applicable to individual string and sequence fields [or will/should one day be, except/as noted in builtins\structs.e], any (traditional numeric) subscripts, slices, append, prepend, and concatenation are meaningless and invalid on structs and classes.
In many object-orientated programming languages, compilation is so painfully slow that extreme measures are taken to avoid/prevent changes that might require dependent classes be recompiled. There are no such considerations in Phix, since it would probably take longer to test than recompile anyway, however of course it retains the notion of a fixed interface, albeit an implicit rather than explict one, behind which rather drastic changes can occur without requiring any external source code changes whatsoever. Obviously the standard non-OOP file-level encapsulation which prevents inadvertent interference by unrelated code is equally applicable to structs/classes, which also have similar scope rules for their fields as local variables do in traditional routines - while you might have access to s.name, the standalone name field is not otherwise itself exposed in any way, nor is there any problem with different structs each having their own name field, all potentially in a different position, or even sometimes string, sometimes function. For more details see the private workings of the autoinclude builtins\structs.e.
pwa/p2js: At the time of writing (version 1.0.0) there is no attempt whatsoever to support classes.
There are actually four different types of structures:
All four are reference types: each instance must be created via new(), and if saved in more than one place, modifying any modifies all such copies/references.
In particular you should note that the result from new() is not normally suitable for passing to repeat(), similar to allocate() I suppose, and instead you should typically invoke new() n times to populate a sequence of length n. Obviously however a single new() can suffice in a repeat(dummy,n) style scenario, whereby you shouldn’t be modifying any of them that haven’t been replaced anyway, and hence don’t care that modifying one of them modifies the rest. The original design also had a sequence-based type, with copy-on-write semantics, however it proved much more difficult to implement, and besides any benefits that might have bought are probably much better obtained via the traditional myseq[MYENUM] style syntax anyway. Another way of saying that might be: Why would you bother to introduce a entirely brand new type system and syntax if it is not radically different to whatever you already have?
Some performance has been sacrificed in the name of programmer productivity, simplifying and managing complexity, enhancing and enforcing type checking, and being flexible enough to cater for as many forseeable needs as possible. That is largely true of any similar system, including object orientated ones, admittedly [at this time] probably more pronounced in Phix than say C++/Go. Not a problem for several hundred or even thousand structs/objects, however (for instance) a standard phix sequence holding 4096 x 2160 pixels will seriously outperform invoking new() more than 8 million times, and not necessarily just during initialisation. Obviously, should benefits such as improved code clarity fail to outweigh a significant performance hit, then in that specific case structs/classes are quite simply entirely inappropriate and should not be used.
Also note that structs/classes are not directly comparable: you cannot use sort() on sequences of structs/classes, instead it would have to be a custom_sort(), or even better yet use a class rather than a sequence to contain not only the list of structs/classes but also the internal/private method(s) needed to compare and sort them.
Likewise, although such operations may still be applicable to individual string and sequence fields [or will/should one day be, except/as noted in builtins\structs.e], any (traditional numeric) subscripts, slices, append, prepend, and concatenation are meaningless and invalid on structs and classes.
In many object-orientated programming languages, compilation is so painfully slow that extreme measures are taken to avoid/prevent changes that might require dependent classes be recompiled. There are no such considerations in Phix, since it would probably take longer to test than recompile anyway, however of course it retains the notion of a fixed interface, albeit an implicit rather than explict one, behind which rather drastic changes can occur without requiring any external source code changes whatsoever. Obviously the standard non-OOP file-level encapsulation which prevents inadvertent interference by unrelated code is equally applicable to structs/classes, which also have similar scope rules for their fields as local variables do in traditional routines - while you might have access to s.name, the standalone name field is not otherwise itself exposed in any way, nor is there any problem with different structs each having their own name field, all potentially in a different position, or even sometimes string, sometimes function. For more details see the private workings of the autoinclude builtins\structs.e.
pwa/p2js: At the time of writing (version 1.0.0) there is no attempt whatsoever to support classes.