On Sun, 09 Jul 2017 17:04:09 +0000 Andrew Williams <[email protected]> said:
> On Sun, 9 Jul 2017 at 10:12, Carsten Haitzler <[email protected]> wrote: > > > On Tue, 04 Jul 2017 14:12:10 +0000 Andrew Williams <[email protected]> > > said: > > > > > Hi all, > > > > > > This topic is something that has crossed my mind as I look at our current > > > APIs and consider the big push to Eo stable. We have focussed so far on > > > exposing the current APIs in an object oriented manner which is great for > > > inheritance and standardising events etc and also powerful for generating > > > bindings in object oriented languages. > > > > > > What I am unsure about, however, is are we matching expectations from > > users > > > of those languages when it comes to seperation of concerns, thin display > > > layers and packaging data logic/behaviour with the related data types? > > > > > > Cedric's presentation about MVC was an inspiring introduction to what we > > > can do to reduce writing a lot of ui code where the data really defines > > > what should be displayed. However this does not necessarily solve how > > many > > > APIs we have on our elm widgets (for example) which relate to data > > > manipulation rather than display logic. > > > > this also does not solve complexity for simple use cases... it makes it > > more > > complex. so it's not a silver bullet. > > > Then the relevant question is are we aiming to primarily support the simple > use cases or the complex ones? And does that change over time (I.e simple > now with an aim to add helpers for complex situations later)? mvvm -> complex use cases. old school api style -> simple use cases. if all i have is a list with 20 fixed/known string entries to choose from creating a whole model thing is overkill to the max. i just want to add 20 items with their strings and some value to know what is selected. if i have a massive file tree of 100,000 items then we're "complex" (or just large) and it's justified for performance. if i have some complex mapping of file properties to fields in a list (icon, label, type etc.) then indeed mvvm/mvc is nice. > > Do we have an opportunity here to split these apart so that (taking text > > > markup as an example) we could have e.g. String (especially important > > when > > > binding to languages that understand ;) ) that provides insert/replace > > etc > > > then MarkedUpString which provides additional markup handling. Both of > > > these could be passed to, for example, entry as the text model so we can > > > avoid exposing all the data related apis of widgets in the process. This > > > would save a tonne of apis on the widgets and other graphical components. > > > > i think this would be a bad idea. we are then double-objecting for labels. > > make > > a string object first then tell label to use that string obj. it's > > certainly > > more complex and requires more steps in every language. > > > I was meaning to use the MVC illustration as the example hence we're not > doubling anything - if we pass String model it's plain utf8, if we pass a > MarkedUpString or similar (which inherits from String) then we get the > extra cool stuff. right now strings are not objects at all. so you add an extra object for every widget that needs to deal with a string. widget object + string object. double objecting. > The equivalent in a non-MVC api would probably be text_set vs > markup_text_set as we can't overload. > > The reason I raise it is because most of the languages we are binding to > have String already and some languages already have the concept of an > annotated string too. > > Andy > > > > > Is there a central document to the core types and design principles of > > our > > > new API? I think it's going to be critical to the success of a compelling > > > developer experience for efl going forward! > > > > > > Thanks for reading, > > > Andy > > > > > > -- > > > http://andywilliams.me > > > http://ajwillia.ms > > > > > ------------------------------------------------------------------------------ > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > > enlightenment-devel mailing list > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > > > > > > > > -- > > ------------- Codito, ergo sum - "I code, therefore I am" -------------- > > The Rasterman (Carsten Haitzler) [email protected] > > > > -- > http://andywilliams.me > http://ajwillia.ms -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
