Is the new framework considered complete? Looks to me that we will be losing a bit of functionality that we have now for desktop. For instance, I do not see how you can initialize a memory block from a text string (now use mb = s). I don’t see a way of initializing a memory block from the text class at all. And I now make extensive use of memoryblock.stringvalue and not sure if there is an equivalent for that either. If there isn’t an equivalent I will have to recode and am afraid will lose a lot of speed. I understand replacing ‘string’ with ‘text’ but I don’t want to see the memoryblock capability hurt in the process. Am I missing something?
No, though the area in your question is more or less done.
You have to go through a Xojo.Core.TextEncoding object.
Memoryblocks are bytes.
In the old framework strings have this dual nature where you can treat them as if they are bytes and also as if they are textual data.
The new framework separates that much more clearly
So first if you have TEXT you convert it to the BYTES that you would get for a specific encoding http://xojo.helpdocsonline.com/textencoding$ConvertTextToData
and you can go the other way (see ConvertDataToText on the same page)
There are examples on the pages I referred to
Ok, I see that the ConvertTextToData is a good replacement for the initialize memoryblock from string. But is there a replacement for .stringvalue. I use .stringvalue extensively to move a range of bytes from one memoryblock to another location within another memoryblock. Moving bytes using a loop will be much slower.
Heh. StringValue to move bytes is exactly on of those “really hack things the old framework let you do”
Strings are not bytes and bytes are not strings but in the old framework they were often synonymous or at least treated as such.
Look over MutableMemoryBlock and its methods - append, insert, mid, left, & right probably will be very useful
Norman, I agree that .stringvalue was a bit of a hack. But in some cases a very useful one. Looks like append, left, and right of the MutableMemoryBlock will replace much of the needed functionality. One thing that I do quite a lot is to fill or pad a memoryblock with zeros by using memoryblock.stringvalue(starting_position, number_of_zeros) = “”. With the new framework would you have to create a byte array of zeros (by using redim()?) and append or insert to get the same functionality?
I’m so glad that I ignored those people that kept saying to me “string is data, you can use it as data” back in the day - I’ve always used MemoryBlocks for data and strings for text, and still do, and I’m glad I didn’t listen to those people then.</sarcastic snarky comment>
The same people probably never got over UTF-8 and Unicode, anyway. Not to mention accented text 
I kind of agree with Norman and kinda don’t. Even though .stringvalue implies that you are doing something with a string, the method was most useful for moving bytes from one memory block to another and also get some padding (with zeros for free). This method is roughly equivalent to either memcpy or memmove ‘C’ statement and is very fast. I replaced a number of .left and .mid and other calls with .stringvalue because it is so fast. I fear that when I migrate to the new framework I will give up the speed that .stringvalue provided. I wish Xojo would bring back a method with equivalent functionality and rename it if it make sense. Call it bytecopy, bytemove or whatever. I believe that Xojo tried to eliminate anything that had string in it and went overboard in this case.
As an example, to put 100 zeros at offset 50 of a MutableMemoryBlock you could:
MyMB.Mid(50, 100) = New MemoryBlock(100)
You can always replace, append, or insert a given MemoryBlock into another MutableMemoryBlock- so I’m not sure where you’d lose speed compared the old framework.
Travis, thanks for the reply. You are not doubt correct. I will have to do some experimentation to create a cheat sheet of “old ways” and “new ways”. I’m sure I will not be alone in this regard. I expect the transition to the new framework for longtime users could cause some pain. I understand the need for the new framework and commend all the work you guys have done to bring it to us.
Shows how little I’ve been paying attention to the new framework, didn’t realize that we now have mutable and non-mutable objects. One of the things with Obj-C that I dislike!
Sorry to thread hijack, but is there a way to tell if the object is mutable or not?
By its class? Or are you looking for a list of which is which?
There are some optimizations which are possible if you have immutable versions that are not possible IF you have always mutable ones. And they can be significant like not having to copy immutable memory blocks to write to socket/file/binarystream etc because you know they cant be mutated while you are writing them to the socket/file etc.
So you cut memory usage in half in those cases.
And there are other optimizations like this where the impact can be significant.
Immutable types, especially for MemoryBlock, provide the opportunity for big performance wins. For example, we can avoid extra memory copies by passing in an immutable MemoryBlock into things like socket events.
Do an IsA check?
Under Obj-C most functions return an immutable object, I have encountered mutable objects from a function (don’t recall what), so when you start using Obj-C, especially when coming from Xojo where almost all objects are mutable, it’s frustrating. It also took a while to figure out how to tell which objects are mutable and not.
Awesome!
I understand why, but when coming from ‘traditional’ Xojo to split objects, it can be frustrating as I explained above.
The other thing I hope is that the convenience mutators (such as mutableCopy in Obj-C world) can be recursive. Several of my apps use property list files, the functions for reading a property list all return a immutable object, so when I want to modify the data, I have to make a copy of the object using mutableCopy, then walk through each element and also create a mutableCopy on that element. ??? (too much hassle). If I use mutableCopy on say a NSDictionary, I expected any nested dictionaries to be mutable also.
Memoryblocks is one case where we knew we had this issue in the old framework where we could consume more memory because of the mutable version and an immutable one was really useful to avoid this.
Not sure there are a lot of other spots where we’d need to do this.
At least I cant think of many off the top of my head.
One of Xojo’s strengths is not just x-plat, is that for a lot of things it’s far more convenient than other tools, I’d hate to see that disappear.
g.drawstring "hello world", 10, 10To draw a string in Obj-C, you now have to use CoreText (which is very very flexible), but you can no longer draw text with a single line (that I know of). There were functions in CGContext, but they’ve been deprecated so I won’t touch 'em with a barge pole.
I have to admit I worry about that too with the new framework… I worry that it will make Xojo no longer fun/enjoyable to code with and instead make it feel like slogging through mud.
Time will tell.
Oh trust me we get that
This particular case was one where it made a lot of sense since for some operations we HAD to take a copy in order to make it so what you thought would happen did happen
imagine you did
- create memoryblock
- put data in memory block
- send mb on socket - which may take some time to actually write all the data to the wire
- mutate mb
the sending isn’t synchronous despite it appearing to YOU as being synchronous
we we HAVE to copy the data into some internal buffer
otherwise the changes in step 4 could alter what data gets sent … from step 3 which would surprise the heck out of everyone
and that would be bad
immutable memoryblocks make this go away because we know you cant change one
and if you DO want to mutate it you create a new one - YOU control when its copied
And thats true coming in as well
So in this case an immutable memoryblock is VERY useful and makes things more efficient and safer overall
But you’ll notice most other classes (ie Text) that have a counterpart in Obj-C are already mutable
It makes things simpler to not have to deal with that choice - so we’re cautious about introducing mutable & immutable versions