Writings from the sticks

Should be a great WWE match up

Really the question was “should I use a class or a module?”

There’s not really global “Oh always use X” answer here.

But usually if you find yourself wiring code that passed data to a method and you have a group of methods that collectively define a “data type” then you probably want a class.

What do I mean by that ?

Suppose you create a structure and put it in a module. And then that module has all kinds of methods that perform some kind of operations on that structure. That really probably _should_ be a class and all the methods in that module methods in the class.

Modules, or namespaces, arent as a mechanism to define a data type. This kind of style is very classical non-OOP design.

There _may_ still be reasons you want to use this style though. Yoi might use it when the data you’re dealing with is used for a declare or other external API and so your choices ARE limited by what declares can accept. There _may_ be other ways to deal with this situation but it wouldn’t be the worst choice to use a namespace in such a case.

Sometimes when you want to subclass a control you want to retain the property name the Xojo control uses, but you want to add some custom functionality by putting a computed property in place in your subclass.

In the long run this makes your subclass a better drop in replacement. You dont end up with the case where the superclass has a property named one thing, like Text, and your subclass has a similar property named something else, like Caption.

For some properties the IDE will prevent you from doing this at all. Basically IF the property you want to do this with is named TEXT you cant create a subclass with a computed property named TEXT because the IDE will stop you – TEXT is a data type and Xojo will stop you from using that name since TEXT is a data type.

Most times you’re stuck.

Notice I say “most times”

There ARE ways to make this work – but it involves working AROUND the IDE outside of the IDE. And it can be “fragile” – if you do anything that would alter the signature in the IDE it will fix it for you then you have to redo things.

When I have wanted to do this I will name my property something memorable – often “Caption” or something mostly suitable but still not the name I really want.

Then I save as text (xml would also work since its mostly plain text). Then I open my project in a text editor like BBEdit & I find the item I named “Caption” and rename it “Text”. Save the edited text and now get the IDE to reload the project.

And there’s my property named “Text” as I expect and I can then also edit and fix any code in the getter & setter and the IDE wont fight me.

I’ve submitted a feature request to make it so that if there is a property on the super class that has the same name as a data type like Text that the IDE permit me to make a computed property on a subclass that shadows that one.

In the mean time this is a workaround.

There are some really handy pragmas that can help you speed up your code a lot if you turn off the things they deal with.

Normally Xojo puts in extra checks to make sure you dont exceed array boundaries and dont overflow the stack on recursive calls. The list is on this page but I’ll repeat a few here

BackgroundTasks Enables or disables auto-yielding to background threads.In addition to the pragma directive, specify True or False. You may place this pragma anywhere within the method to enable or disable background threads as necessary.

BoundsChecking Enables or disables bounds checking.In addition to the pragma directive, specify True or False. You may place this pragma anywhere within the method to enable or disable bounds checking as necessary.

NilObjectChecking Controls whether to automatically check objects for Nil before accessing properties and calling methods. In addition to the pragma directive, specify True or False.

StackOverflowChecking Controls whether to check for stack overflows.In addition to the pragma directive, specify True or False. You may place this pragma anywhere within the method to enable or disable stack overflow checking as necessary.

These 4 can be VERY handy and can improve speed a lot. But, I would suggest ONLY enabling them in release builds AFTER you have debugged everything satisfactorily.

Why ?

Enabling them in a debug build may mean you get odd crashes of your debug builds because none of these checks will be done. And if you have an issue that causes one of these you may get a hard crash of your app being debugged instead of breaking into the debugger where the issue exist.

And there is one more you might need to carefully determine if you want it enabled or not

BreakOnExceptions Used to override the BreakOnExceptions menu item in the IDE. The possible values are: True, False, and Default. You may place this pragma anywhere within the method to enable or disable breaking on exceptions as necessary.

In conjunction with the others if you turn break on exceptions off as well then you can have a horrible time trying to debug.

Often I will use code like

#if debugBuild = false
  #pragma BackgroundTasks false
  #pragma BoundsChecking false
  #pragma NilObjectChecking false
  #pragma StackOverflowChecking false
#endif

at the beginning of methods so that during debugging runs I still get the exceptions if I do something that would cause a crash in a release build. Eventually I may also add

#pragma BreakOnExceptions false

outside that group because I have debugged that code well enough and tested whatever exception handling in there I’m happy with it and can ignore any exceptions the code might raise.

Careful out there !

Sure I badly paraphrased the line from Wizard of Oz but this isn’t a word junkies blog. Or a Word© junkies blog either 🙂

Stupid tech jokes aside this one is about Ptr and Memoryblock and their interesting relationship.

In Xojo a memory block is just that – a chunk of memory acquired in one of many ways, that usually can be manipulated in lots of ways. They can be really useful for all kinds of tasks like dealing with byte oriented data (files, binary streams) as well as more high level things like manipulating UTF-8 data since at the very lowest level UTF-8 is just special runs of bytes that we interpret as “characters” or “text”.

But then, everything in a program is JUST runs of bytes that are interpreted in special ways depending on what the bytes are, whether they happen to be “data” or “code”.

And this is where things get interesting.

A recent post on the forums did

dim p as ptr = d //d is a delegate like "AddressOf methodName"
dim mb as MemoryBlock = p
dim id as string = Crypto.SHA256(mb)

So exactly whats going on here and why might this be a problem and why might it cause a crash ?

AddressOf returns, as it states, the in memory address of whatever method you ask for. And this address is a ptr – a specific place in the running instance as loaded at this time which _could_ be different next time you run the application. This tends to be an OS level security measure.

Memory blocks CAN be created from a Ptr. Usually this is so you can use it with a declare that creates and allocates some memory and returns a pointer to that allocated chunk of memory. But, a pointer is a pointer is a pointer. So it really doesn’t matter where that pointer came from. And with this particular pointer

dim mb as MemoryBlock = p

being the address of some method, or executable code, it just happens to be in our program and its memory space. But it is relevant that is its executable code.

And then when this code tries to access that ptr it tries to READ the code, not just the ptr, since the base address of the memory block is just where “the bytes that make up thi memoryblock” are.

Crypto may die for one of two reasons. First – the OS may bock you from reading the executable code this way. Secondly Crypto would need to know how much data to encrypt. And a memoryblock created from a Ptr doesn’t have a known size. So SHA256 may just try and read -1 byes (which is a HUGE unsigned number) and crash because of that.

If you’re going to mess with Ptr’s & memoryblocks make sure you know what toes you’re prepared to lose 🙂

One day on IfNotNil we were discussing byte code and interpreters.

And the conversation came around to old CPU’s like the 6502. One many folks cut their teeth on. My first computer was a TRS-80 CoCo and after than I stepped up to an IBM clone; a TI Professional which lasted me through University and up until I started my first job after school.

As part of the discussion it was hinted that writing a byte code interpreter for any one of several old 8 bit CPU’s might be an interesting diversion. And it might also prove to be useful as a learning exercise for others.

Since the 6502 is an 8 bit only machine it basically is a “byte code” interpreter by its very definition. Each opcode is entirely contained in one byte – instead of like some current machines today that have very wide opcodes.

As such its possible to encode EVERY opcode and an associated handler in a simple table of 255 entries that, when an opcode is encountered, the handler is fetched from a table of handlers and invoked.

Those handlers are all 0 parameter methods that fetches whatever necessary operands it requires, executes the specific instruction, sets registers, and returns.

Here’s my evolving project on GitHub

Methods should solve a single problem, answer a single question, or otherwise do one thing.

When you, the author, are asked “what is this code going to do ?” you should be able to say it in ONE sentence without the use of conjunctions or disjunctions – no ANDs and ORs required.

The upside to such a description is that this often can make method nice and short. A “page” of code or less so its easy to read and see that the stated purpose is met.

As well you should be able to avoid side effects as the code answers the one question its asked, or solves the one purpose its started to solve (esp if you adhere to the Law Of Demeter)

What do I mean by all this ?

Often in code you have a need to know IF some variable contains a value that IS representative of some kind of data. Is the value in a string a date, an email address, a url your code knows how to handle, an integer, a floating point value, a boolean etc.

In one bit of code I’m working on there are strings that may hold one of several types of data. And we need to know what data type that data is. So there is code like the following to examine the value and decide what kind of value this is

Select Case True
Case value.Left(1) = """" And value.Right(1) = """"
  type = "String"
Case IsInteger(value)
  type = "Integer"
Case IsRealNumber(value)
  type = "Double"
Case value = "True" Or value = "False"
  type = "Boolean"
Case value.Left(2) = "&c"
  type = "Color"
Case value.Left(2) = "&h"
  type = "Uinteger"
End Select
End If

The calls to IsInteger and IsRealNumber examine the passed parameter and return a true false value. And do NO more than that. They do not alter the value as that could cause side effects in other code.

When you write code that does more than answer the question asked you can cause yourself unnecessary work. How so ? Imagine that the IsInteger call above actually altered the value passed in. I would need an extra variable to make a copy of that value before calling it.

As well, its not obvious that this IsInteger method WILL alter the value passed in just by reading the code. At the time you write this code you will probably remember it. But in 6 months you won’t. Nor would someone else reading the code expect that should happen.

Dont do it to yourself or to your team mates.

If you have an IsX method then you probably also need a “ConvertToX” method. So for the example above IF some data can be determined to BE suitable for an integer then a “ConvertToInteger” method would make perfect sense.

Don’t do them in one step and don’t alter the data your given (ie/ do not use a byref parameter and alter the original data)

You future self will like your code a lot more.

Or “write once”

This is a form that LLVM uses for its IR when compiling. It makes certain kinds of analysis much easier to perform as its simpler to determine how variables are affected long term and what their life times are.

And Rust uses it for EVERYTHING – you literally have to tell Rust that a variable should be “mut” or mutable.

Now you might think “OMG this makes things SO difficult”.

But in reality it actually makes things easier especially in multi threaded code because you cannot from one thread modify something in a way that could cause side effects in other threads.

And the really nice thing is that Rust actually can tell at compile time that your code is thread safe – this is really pretty cool and the more I learn about Rust the more I like some of the design decisions they made when creating the language.

This style is much harder to use in Xojo. You’d have to make every property that is exposed a computed property that you can assign once. And this is a bit of work to do. But it is possible. Again doing this could help eliminate certain kinds of bugs. Those that come from side effects because in one place you alter a property and yet it shouldn’t be or wasn’t expected to be.

Certainly computed properties can help as it makes it possible to put code in the setter so you can see when a property is modified. This is handy as heck and something I use a lot to try & make sure I don’t have weird side effects. Or when I do I can convert the simple property to a computed one and then put break points in the setter & getter.*

While SSA form has certain qualities that work well in languages & tools designed around this form, using it in Xojo _might_ be more pain than its worth.

Why ?

Suppose you create a custom subclass of a control and want to use SSA. If you have added properties on your subclass they may get initialized when the window is opened. Should your SSA property be accepting that value and no others ? Or should it only accept the first value it is assigned from code ?

Determining which case you’re dealing with is possible (see https://www.great-white-software.com/blog/2019/05/31/making-a-constructor-sometimes-illegal-to-call/) but now you have a lot of extra code in every property you want to be this kind.

In total I’m not sure that th effort is worth it for every property. But for a handful it might be.

• That you can switch a simple property to a computed on or method get / set pair and NOT have to change other code is actually one of the things I appreciate about Xojo.

Joel Spolksy has some great blog posts

Several I re-read from time to time just to refresh my recollection of them or to glean something new from them I may have missed on one of the tens of rereads I did.

I really like his blog posts about organization style, functional specs and other aspects of software development. Mostly because he’s done a lot of this more than once.

Some of my favourites

How to be a program manager It’s a great read and talks about WHAT a program manager does and who should, and who shouldn’t be the program manager and why. And it has some excellent lins to other posts about functional specs. Perhaps the BETS bit of advice in this one is

To make sure that the debate happens respectfully and on a rational basis of facts, it’s absolutely critical that the program managers and developers be peers

https://www.joelonsoftware.com/2009/03/09/how-to-be-a-program-manager/

Painless Functional Specifications is another great one and has sound advice for anyone who writes software. Starting WITHOUT a spec is masochistic. Or as Joel writes

It’s as stupid as setting off to cross the Mojave desert with just the clothes on your back, hoping to “wing it.” 

https://www.joelonsoftware.com/2000/10/02/painless-functional-specifications-part-1-why-bother/

Setting off without knowing where you’re going, how you plan to get there, or even where “there” is is simply crazy. And a waste of time and effort

If you haven read his blog I would – especially the archives as there is a lot of really good advice on it.

Yeah again 🙂

Fixed a bug where it would write the wrong value into the data on the clipboard and so it would create an incorrect enum to be pasted.

Thats been fixed

More things on the way !

I’m not sure thats a word – propertiness

I’m using it to describe something that acts or behaves as a “property”

What defines something being a “property” ?

C# uses

A property is a member that provides a flexible mechanism to read, write, or compute the value of a private field. Properties can be used as if they are public data members, but they are actually special methods called accessors. This enables data to be accessed easily and still helps promote the safety and flexibility of methods.

https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties

There’s no specific requirement that a property be a simple type or a computed property – just that it has the ability to be read, written or possibly can access a private member.

A property could be implemented in Xojo using :

1. a simple type like an Integer, Color, etc
2. a computed property
3. a pair of methods

Each has pro’s an cons

A simple property allows you to quickly and easily add a some setting for whatever you are adding this to. But, you cant easily make such a property read only or write only. And your code wont notice when this is set since there’s no event or anything to tell you it has been set. Subclasses cannot “override” this kind of property but they can “shadow” it.

A computed property is a simple set of get / set methods that are associated with the property. The setter has an implied parameter, value, that is the same type as your computed property. The getter has no such parameter and returns a value that is the same type as the computed property. The upside to this kind of property is now you have a place to put code to react to changes in the value, or to know when something accesses the value by putting code in the getter. Subclasses cannot “override” this kind of property but they can “shadow” it. This often has a protected or private backing variable that actually gets set or read – but not always as it may be derived from some other data held internally like the ubound of an array, number of rows in a listbox, etc.

A pair of methods, one define to return the value of whatever type and one to set the value, using assigns, are almost identical to a computed property. The biggest difference here is that, because methods ARE virtual this kind of property can be overridden by subclasses if they simply implement one or both of the methods that define the property.

Perhaps the most unique and useful aspect of these different types is that, in code that uses the property, you dont have to care what implementation is used. And, in code that creates & defines the property you can safely switch from one type to another as long as you maintain the same API (ie/ if a property is initially readable & writable then you have to maintain that when you switch to a different style otherwise code that expects to be able to write that property will no longer compile)

The upside to the last style is that the means you can “define properties” on an interface. Since a property isnt a specific implementation but a behaviour an interface can define the getter & setter and then any implementors of that interface now can expose that property with whatever custom implementation they need to implement.

Have fun !