[NUG] *Re: API 2.0

[Norman Palardy]

> On Mar 13, 2019, at 9:26 PM, Jon Ogden via Nug <nug at xojousers.com> wrote:
> 
> You are correct.  Except working with memory blocks is somewhat cumbersome.  And Xojo doesn’t really have true binary or hex types.

Theres no such thing as "binary type" or "hex type" - binary and hex are ways to show the data in a byte in one of two possible forms (and octal is another)
Uint8 is a byte - so is an int8
The only difference is that one is treated as signed the other unsigned
But at their lowest levels they are the exact same bit patterns which we maybe write in binary or octal or hex or decimal

> Yes there’s the &b and &h to represent the literals but it’s not a true type.  I can’t do a Dim MyWord as Binary or Dim MyWord as Hex.  It would be nice if Xojo had real types for binary and hex and octal.  Then I could just look at the hex data coming in from a socket.  That would sometimes be quite nice.  Maybe there is a way to do that and I just haven’t figured it out...

Few language have these types - since they have other types that can be used (char, int_8 etc) 
Some have Byte but its basically a synonym for int8 or something similar (at least you can treat it that way)
Plop it in a memory block -examine the contents and debugger will show you the contents in hex

What you want is a different viewer in the debugger
That doesn't require a different type

>>>> Strings will still have the dual behaviour BUT for textual data will basically be what Text was - just accessed using "string" apis and methods
>>>> 
> 
> Makes sense.  And I think Strings is a datatype that people are so used to as it’s been used in every single BASIC language course since the beginning of time.  And lots of languages or so much more loosely typed than Xojo and use strings, etc.  I get the problems with them though particularly when you are really dealing with hex characters like Telnet negotiation options.

But few that have "string" also allow you to use it as an arbitrary bucket of bytes

> Yes, which is why CancelCall should be used in the Close event of the window.  No, I am talking about strange random errors that are not reproducible.  I had one that was an Exception for changing the dictionary while iterating over it.  Now, that was internal to the timer and outside my control.  Joe admitted it was a problem at one point but said he thought it was fixed.  It doesn’t usually happen but that and other things with it have happened enough that I’ve stopped using it and gone to using Karen’s SingleActionTimer class.  That’s much more reliable and has never given me one of these random bugs.  I’ve griped about this on the forums plenty but Xojo only wears good filter glasses.

Iterating over a dictionary using an iterator will raise an exception if you alter the contents of the dictionary while iterating
This is actually very common in a lot of languages

Basically it cant guarantee that you will visit all items and so it throws up its hands and says "you should start over or something but I cant go on like this"

>> Now what IS buggy is using WeakKAddressOf
>> It does not check to see if the target has disappeared and do nothing if it has
> 
> Definitely.  I’ve discovered that.  Yeah, it prevents circular references but if the target has disappeared it causes an issue.  You are correct in that!

I know there are bug reports about this one but not sure if / when someone will tackle it
I wish they would as the IDE could have made use of this but ....
Since Joe left in 2017 I dunno if some of these things can / will get fixed in the next while

> Problem is it was just a very cumbersome way to do it when probably 90% of the time plain String works just fine.

Right up until it silently screws you over :)
That something that should never happen
Thats what TEXT and AUTO etc tried to deal with by being very explicit and complain loudly when they failed to do as expected

And I'm quite sure you'll see a lot of that in API 2.0

Bob's notes from XDC 2018 are useful to read over
https://www.bkeeneybriefs.com/2018/04/xdc-2018-android-xojo-framework-and-api-2-0-notes/