Compiler patch for runtime reflection

Adam Wilson flyboynw at gmail.com
Thu Oct 27 11:42:46 PDT 2011


On Thu, 27 Oct 2011 00:14:35 -0700, Jacob Carlborg <doob at me.com> wrote:

> Are you saying that you consider using D for this Horizon project? I can  
> recommend you take a look at DWT: www.dsource.org/projects/dwt
>
> Somewhere down the road I've planed to create an interface/window  
> builder for DWT using XML or something similar. I'm thinking something  
> like how it works on Mac OS X using Interface Builder.

I am, and I have looked at DWT. My problem with it is a one that is  
endemic to open-source UI framework. Microsoft recognized a decade ago  
that UI widgets whose look-and-feel is defined and controlled by the  
Operating System are going the way of the dodo. Out of that realization  
WPF was born. UI designers today want the ability to control every pixel  
of the UI's presentation. And the reasons for this are two-fold. The first  
is that it turns out that most OS designers are fantastically bad at UI  
and design in general. It takes epic piles of cash to pull of a decent one  
and even then there is a still a "programmers were here" look to it (with  
the notable exception of iOS/OSX where designers rule the roost). The  
second is product differentiation. Nobody wants an app that looks like  
every other app because it actually becomes impossible for the user to  
distinguish which app works best for them. Users ONLY look at the UI, and  
if the app doesn't look good, they wont "buy" it, even if it's free. This  
is non-negotiable. Users, when given two apps that do the same thing, even  
for different prices, will pick the prettier one every time, because the  
prettier one is perceived as being "better". It's called the  
Attractiveness Bias and it is a well-known principle in the design world.  
Who would you rather look at all day, Alessandra Ambrosio or Rosie  
O'Donnell? I rest my case.

I maintain that this is prime reason that Linux on the desktop has failed  
miserably, and I think Android proves my point. Android's key win is that  
it put a usable UI on top of Linux. People never had a problem with the  
price of Linux, they just couldn't stand to look at it. The Linux Desktop  
LOOKS industrial and it's apps for the most part look the same (I know of  
a few outliers that did a good job, but it isn't the norm). My point is  
that the day of cookie cutter apps is over. Anyone designing for that  
paradigm is history. Microsoft's latest UI paradigm, "Metro", is just a  
different cut-down version of WPF similar to Silverlight. Microsoft has no  
plans to go back to OS controlled UI styles; Metro and WPF are the plan  
for the next 15 years. (I attended the MS BUILD conference, they made this  
plan very ... nay, EXTREMELY clear).

Open-source is chronically behind the big boys with money, precisely  
because FOSS doesn't have the money to sling around for Testing and  
Usability Studies, and most FOSS guys don't want to mess around with that  
stuff anyways. You see FOSS guys tend to be engineers; they can put up  
with, and even like, industrial looking interfaces. But programmers also  
have a giant blind-spot when it comes to users. Most programmers view  
users as a lower species and assume that they will be delighted by  
whatever the programmer deigns to bequeath to them. But if you look at the  
successful people in the tech industry (*ahem* Steve Jobs) you'll find an  
attitude that is the exact opposite. Jobs was so focused on delivering  
what the user wanted that he would publicly berate any programmer who  
thought they knew better than the designer. While I don't necessarily  
agree with Jobs' management style, there is a reason why Apple is the  
second largest company in the world right now, and it has nothing to do  
with how good Apple's engineering is (which I hear is average at best).  
Despite programmers' best efforts, the world of technology is no longer  
controlled by programmers. For better or worse, users determine our course  
now. The open-source community would do well to embrace the user.

But without a first-class UI framework, that will never happen. In terms  
of capability and usability, both Apple and Microsoft have beat the best  
FOSS has to offer by a decade at least. I looked, searched, and scoured,  
but the fact of the matter is, even the usable FOSS UI offerings are  
pitiful when compared to the commercial offerings. The Horizon Project got  
it's start because there has been a trend in recent commercial UI  
offerings from towards increasing reliance on the operating system itself.  
Metro XAML just flat won't work on anything other than Windows 8,  
Silverlight is a second class citizen at MS now, Cocoa only works on Mac  
etc. My goal with The Horizon Project is to create First-Class UI  
Framework for multiple platforms so that programmers don't have to rewrite  
the UI from scratch for each new platform they want to support and then  
open-source it so that the commercial OS vendors can't pervert it for  
their own purposes. I want to put [some of] the power back into the  
programmers hands.

Apologies for the length, but this is a topic that is of some interest to  
me. :-)

> I don't understand this one. Should the compiler disable reflection as  
> soon as it sees malloc/free? On what level should it be disabled? I  
> mean, the runtime needs to be able to use these functions to implement  
> the memory manager, i.e. the garbage collector and other things as well.

The idea is to automatically prevent reflection access to sections of the  
program where using direct memory manipulation could potentially result in  
security holes but provide a way out for the programmer if they really  
wanted it. C/C++ is famous for programmer bugs around memory handling. If  
the compiler automatically disabled reflection, by sticking @noreflect in  
front of a function that used malloc or new, it could potentially prevent  
those types of memory manipulation flaws and help keep the Reflection  
attacks to a minimum. It was an idea that I was throwing out there. But I  
don't know enough about D yet to know if it's the right way to handle it.  
And I have to admit I am little confused though as I would hope that  
Reflection would be disabled on the GC, because I have never personally  
had a reason to reflect into the GC...

-- 
Adam Wilson
Project Coordinator
The Horizon Project
http://www.thehorizonproject.com/


More information about the Digitalmars-d mailing list