And im right then?? That this could well emulate file of data?? Or better memory of data
It does the same kind of thing. Though in this case a FileStream would be a better match? Either way it takes a nr of bytes, not a nr of records.
Ok, but internally it behave like “file of…” ?
and im just wondering, why does the …stream.write(…) takes a pointer as a parameter??
why not the “real” data, means, why not a record/class itself?
How does file of behave special? It’s been decades since I last used file of.
It’s a pointer as it takes raw data. You can’t write classes directly and only structs with simple types.
The typefile needs to specify a constant type and you are able to write endless records of data of the given type to the file, have a look:
var myfile: file of string;
now im able to write, read JUST STRING OBJECTS
var myText := f.Read(myfile, "hello world"); //reads the exact value out of the file and gives it back to the caller:
No Stream doesn’t support reading strings directly.
Ok, i think i will start something by my side to create what you mentioned out, like “File of T”
And did you maybe consider the one post with named tuples??
var myyTuple: tuple of (Name: string, ID: int32, haveLoan: boolean);´ myTuple.ID, myTuple.Name, myTuple.haveLoan //and so on...
I actually would like to know, why did you decide to make tuples as reference types?
Wouldn’t it be faster and less memory-allocation when it would be a record instead of being a fertype. ala class?
I’m not a RemObjects person, but I’d say, it’s because of .NET
See C# for example: https://msdn.microsoft.com/de-de/library/system.tuple(v=vs.110).aspx
C# 7 will bring value tuples but I don’t know what this means for Oxygene.
For named tuples, what do you really want to do? You can just do it by yourself. Or even use dynamic objects.
Ok but .NET now has named Tuples and with c# 7 value-tuples much better, why not Oxygene as well and i tell you why i would often prefer named-value-tuples:
I could always replace my ACTUALLY useless data-records which have 3-5 fields and are just data-holder without any other logic and in addition to that fact, you always need to write your own “<>” and “=” operator to compare your custom records, currently i have 3,4 records which would be so better as named-value-tuples and would save near to 100 lines of code!
And furthermore, the tuple has “GetHashcode” and more, its probably better optimized to fit well in Island, so that the use of it is even more useful, because they fit better in the rest of the island api, in my opinion!
Yeah, but C# 7 is not yet officialy released. Soon indeed, but not quite yet
So, there is also hope that Oxygene might follow, not?
i have a possible new feature^^
Wouldnt it be nice to have a custom data type like this:
TCustom = 0..12, 18..34, 56..100; //the syntax is just a sample
And all values between 13 and 17, 35 and 55 are NOT accessible!
Where you could have multiple rangetypes in one big-range-type, unfortunately, i forgot both usecases i had the days before where this could be really nice…
But whats on your opinion guys??
You could write it yourself? A struct that has an integer field inside it with implicit operators to accept and give integers. It’s not something I plan on supporting on the compiler side.
I would like to talk about some possible ideas/features i really love and would personally love to see being introduced^^
Named Value Tuples (some of the above post)
Multiple Subranges in ONE Subrange (some of the above post)
Subranges which could have a “step” in their definition, which would have the effect that you could define Subrangetypes whose values are just accessible addicted to their step-definition, like:
TSubRange = 0…100 step 2;
This would mean that a variable of that type can just access the values: 2,4,6,8, 10 etc…
4)A Next Custom-Datatype could be the same as an Enum/flag but just WITHOUT the names, for instance:
TCustom = 0,32,64,128,256,512,1024;
That type is able Just to store THESE Values not more not less, and is declared like any other variable.
Would really like to hear your opinions about that
PS: YES, i know it could be done by myself, but it would be really great to get it done via the sugarsyntax of Oxygene/Pascal and let the compiler do the work behind it, and in addition to that, you could then also say, remove Subranges because you could do it by your own.
1 is on the list already. Though not for this release.
2 and 3 have very few use cases so imo not worth doing considering the amount of work involved for such a compiler level feature
OK and whats up with nr. 4 ??
It could actually be implemented easily when you would use an enum as a backing store for it internally
What would I use 4 for? (it’s kind of the same as 1 and 2)
Sometimes it is just better to have this enum logic in an extra datatype without having this enum names like you just need the value logic
IMO: I wouldn’t want to have the language cluttered with non continuous numeric types.
Another Thing i remember today is, why actually isn’t it possible to do this:
ITest = Interface Read(); Write(); end;
TestClass = class(ITest); method Read(Position: int32): Object; //----- the Compiler should still know, that this is the Read() of ITest method Write(Position: int32; value: Object); //----- the Compiler should still know, that this is the Write() of ITest end;
Would really like to understand why that doesnt work, when ist possible in both ways:
technically and/or semantically