options in .fbp files

[dmichiels]

For the moment, IIP are declare like

"record(some:option foo:bar)" -> 

Everything inside " or ' are compiled inside Oz value. In this case, it will give a record and not a String. It's not very clear and logical. I proposed to add a special syntax, like ''' (three single cote) to begin a Oz expression that end at the first "->" see. So that will give :

''' record(some:option foo:bar) ->

[sjmackenzie]

So "xyz" makes a string and ''' xyz -> makes a record?

[dmichiels]

yes, and ''' "xyz" -> make a string also! In fact, ''' is more general than record, because it can be a function or anything else

[sjmackenzie]

In other words one can put oz code in ''' xyz -> ?

[dmichiels]

yes, it is that I want to say!

[sjmackenzie]

So exactly what problem does it solve by implementing this feature?

[sjmackenzie]

I have a few concerns about this approach:

1) FBP makes a clean separation between business logic and component logic. This proposed feature will blur the line between the two types of logic. It doesn't make hypercard so useful. 2) The mozart2 compiler doesn't understand .fbp components so developers might be enticed to write more and more oz expressions in the .fbp file. Thus the probability of introducing errors is greater. As the is no compiler to catch syntax errors. 3) It will make a .fbp component harder to read. Remember average people will read .fbp files. This has an impact on the UI as we now need to design a larger options panel to display and edit oz code. Thus seeing the relationships between components becomes harder. 4) Leave oz code to developers, whom understand this degree of 'complexity', non-developers will have a tough enough time understanding what options are. Let's keep that as simple as possible. 5) I understand the need for passing in different datatypes as IIPs say integer, string, record etc. Maybe keeping the solution we need is to differentiate between basic datatypes and not just open the gates completely?

[dmichiels]

Yours points are true, it's just for the moment it's the case (everything between " is an Oz Expression and not a string), so I want to show it. But it's perhaps more logic to restrict thing. Keep ''' xyz -> to signify that xyz is a oz vavriable, and assure that it's a basic type (record, int, float, String, ...) ?

[sjmackenzie]

Ideally graph.oz will also syntax check the IIP option parameters. I imagine it might be easy to make mistakes there. Lets reduce the possibility of introducing errors in *.fbps as much as possible. Hence at some point it'll be good to syntax check only know correct values.

Yes I prefer the restricted approach but in a way that doesn't compromise simplicity of reading. Honestly I prefer "xyz" -> opposed to ''' xyz ->. When I see ''' I start thinking markdown and I'm waiting for the closing '''. Intuitively we should close with what we opened.

Secondly I'm not sure yet how to intuitively declare the datatypes. Maybe much later we can do introspection and automatically determine the datatypes? maybe we want it explicit? "string(hello)" for example?

That way everything is read as a record then extracted and initialized appropriately. The IIP record is then GC'ed.

What's your thoughts?

[dmichiels]

Make the type explicit will make the expression very verbose, and I think we will loose in clarity... To infer the type : it is not possible to evaluate the expression and then check if it basic type with {Int.is}, {Record.is}, ... In fact, we don't infer, we just check after.

For "xyz" and ''' xyz ->, I wrote that only to :

• show the difference with a string
• don't have escape characters But ''' is very markdown style, I admit. We can keep "..." if it's more clear.

[sjmackenzie]

Okay, I worry about feature creep, if it solves a real problem then go for it!

[sjmackenzie]

Is it not better to just use "5" -> then the component knows what it will expect and do the conversion?

say: {String.toInt +S ?I}

So the component developer has to know this information and communicate it via the component options documentation. This keeps it simple and doesn't encourage the use of oz expressions in *.fbp.

[dmichiels]

That would be too restrictive. We don't need to forget that the IP can be forged, or send by another component. Your solution force all IP to be string! But it's possible to forge only string component, and build conversion component. If the user want to forge the in 5, he forge the string "5" and make the IP go through the component stringToInt. That can work, but it's more work to just create a value (Int, record, ...). I admit that would make the .fbp file without Oz expression.