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)? > 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. 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 ------------------------------------------------------------------------------ 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
