 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Patrick Elliott wrote:
>> moving it around), well.. tough luck, because its **not** in any of
>> their damn documentation, anyplace, as far as I could ever find.
>
> Huh. I didn't think that's how design mode works.
>
Well, the documentation is fairly specific about how it does, just not
how to turn it on. Its basically a mode flag, which when turned on,
triggers, "show_grab_handles", and, "disable_control", or something like
the second one. I don't remember the name. In theory, you could also
trip both of those states *in* the control yourself, but the control
needs to support grab handles, and have a draw state, where it shows
itself in its "not working" mode, and refuses input. In other words,
clicking on any part of it should just trigger "drag", not what ever the
control would normally do when clicked, and it shouldn't, if a display,
react to data coming into it, such as setting its text, etc. Windows,
and certain other standard containers, contain the internal capabilities
of triggering a "go into design mode" message to all of their children.
The problem is, the only application that "supports" this function seems
to be the compiler suite, and there is no clear documentation of how to
use it in your own applications.
There is also an implication, both from how the compiler GUI works, and
the documentation, which implies that any such container, which works as
part of the GUI, can have this setting flipped, and trigger the event,
without making the entire application do it. This is why you can move
around objects in the design GUI, while the GUI itself is still
"functional", including windows, which are themselves elements that can
be placed in other containers, such as the compiler's GUI window. You
still have to implement code to show the "default" state of your
control, and display grab handles, when in that mode, but, in principle,
existing controls, like those that come with the compiler, already have
both. The trick then is, making your container "fire" the event, by
changing its state. Sadly, its not like any of the other states in the
object. You can't set if using the normal methods. Its a **hidden**
function, as is the function to show the handles, or disable the
control, separately. It would have been a **lot** easier if they had
made it an addressable option.
Oh, and just to make things even more fun, some standard controls have
two modes, like the text box "single" vs. "multi-line", which can only
be "set" while the control is in 'design' mode. This means that, if you
wanted to implement a means to add such a control to your own
application, even as something like an element read from an XML markup,
you have to implement *both* the single and multi-line versions in your
application, so that you can instance the correct one, instead of the
**sane** thing, which would be to instance just TextBox, then set it, as
needed, to the single/multiline version you need.
Mind, a lot of this got easier with .NET, and much of it is now
meaningless, but I spent almost a year pulling my hair out a while back,
when the thing I wanted to use it in was likely to be running in Win98
as well as XP.
--
void main () {
If Schrödingers_cat is alive or version > 98 {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New schrieb:
>> That C part of ACID would be covered by the contract-oriented paradigm
>> I think.
>
> Well... to some extent, yes. Contract-oriented tells you the
> relationships with individual objects. The C of ACID tells you the
> relationships between objects. But they're similar concepts, yes.
>
> The contract-oriented paradigm won't tell me if I change the Customer
> class and it breaks the Order class.
In contract-oriented programming, how could you possibly break the Order
class by a change in the Customer class? All you could possibly do is
/violate the contract/ of the Order class.
As far as that is concerned, such a violation /could/ be detected by
static code analysis (within limits regarding the complexity of the
pre-/postconditions), or by running the application in debug mode with
pre-/postcondition checks enabled (within limits regarding test coverage).
I don't see where the C in ACID could be verified any differently.
>>> I can't imagine changing a queue to a stack without needing to
>>> rewrite a fair amount of the code using that structure.
>>
>> That direction may indeed be problematic, but changing from a stack to
>> a double-ended queue shouldn't be a problem, as a stack is just a
>> special case of a deque that provides no access to the "head" of the
>> queue.
>
> True, but then why would you do that if you aren't going to be
> dequeueing stuff at the other end? :-)
Maybe the underlying type needs to be changed to allow doing just that,
to implement some change request (or fix a design flaw).
>> That it's not so easy with the STL is a problem of C++, not OO
>> languages in general. And even with the STL it would be a piece of
>> cake if you had chosen to use a typedef (which you could interpret as
>> a kind of "identity inheritance") in the first place instead of
>> hard-coding the type name everywhere.
>
> Right. I mean, that's a trivial kind of thing. You have the same problem
> with names in Java as you do in C++. If you code your functions to all
> take arguments of type stack, changing to a dequeue is going to require
> tracking all those down, just like if you did it with STL.
In Java, if you'd be smart you wouldn't declare function arguments as of
a certain /class/ type, but of a certain /interface/ type. You can then
easily "upgrade" to a more powerful type without changing any existing
code (except for the actual container object creation).
In other OO programming languages, you could do the same using the type
names of abstract base classes instead of whatever actual implementation
is used.
If you did your homework properly, most OO languages will allow you to
pull off the stunt even without recompiling most of the code.
> The point I was making is that there are lots of paradigms
I presume this sentence was left incomplete? (Otherwise: Erm... yes,
there are indeed lots of paradigms :-))
> Yes. But they're not inherited from each other, and they're not
> necessarily dynamically dispatched. All you're saying is that you can do
> things similar to OO with templates. I.e., yes, the *design* is OO, but
> the implementation need not be, so you're making my point for me that
> you can have generic containers without OO.
But my primary point was that the OO /paradigm/ was highly influential
in the creation of such type libraries - and that a non-OO approach
doesn't get you there, unless you somehow "emulate" OO behavior.
In the case of the STL, the library in a sense uses a "static OO" model:
The implementing classes are /designed/ to be interchangeable without
code change (to the extent that they implement the same "concept"); they
are /designed/ to use the same function names and parameters for the
common functionality. The only thing they lack is a language that allows
them to carry this flexibility over to run-time.
>> Note that data encapsulation /is/ an OO trait.
>
> It's a trait of a lot of languages. It's not the definitive trait of OO.
This discussion seems familiar to me. I'd say it is /the/ most important
trait of OO.
>> And are you really sure they don't use any OO portions behind the scenes?
>
> They might, but that's not the point.
Oh yes, it part of the point I'm making.
> Does the STL's dequeue inherit from the STL's stack, or vice versa?
No, but they both "inherit" from the same "concepts".
>> A library using an OO design does not necessarily imply that you can
>> subclass it, or any of its components.
>
> Right. But then it's just a library. Subclassing and inheritance is one
> of the primary defining features of (class-based) OO. Otherwise, it's
> just a nice way of passing a pointer around, and you might as well do it
> the same way stdio.h does. (stdio is a library with an OO design, yes?)
From an object's caller's point of view, OO support in programming
languages /is/ "just a nice way of passing a pointer around".
From an object implementation's point of view, OO support in
programming languages /is/ typically nothing more than syntactic sugar
to automatically generate implementation details such as virtual method
tables, and (in the case of class-based OO) provide the compiler with
hints about type compatibility.
And, as you say yourself, subclassing and inheritance is one of the
primary defining features of /class-based/ OO. Given that there is
non-class-based OO, obviously subclassing and inheritance /cannot/ be
the primary defining features of OO in general.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New schrieb:
> Darren New wrote:
>> Erlang? Tcl? LISP?
>
> Actually, Ada can do this too, I'm pretty sure, even without using its
> OO features.
"Non-OO mainstream (imperative) language"?
These languages all don't appear to fit that bill.
> If you look at the source for Wings3D, you can see where there are
> pieces of code that basically say "hey, there's a new version of the
> code, load it and run it *without* closing my window, saving the shape
> i'm working on, etc." I.e., the developer could find a bug while
> working, fix the bug, and keep working except with the new code running.
>
> OO isn't going to give you *that*.
I never said it does.
Though it wouldn't stand in the way of that. This is primarily a matter
of the run-time system, not the programming language (let alone software
design) paradigm.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Patrick Elliott wrote:
> Its basically a mode flag, which when turned on,
> triggers, "show_grab_handles", and, "disable_control", or something like
> the second one.
I see. That's kind of what I thought. I thought you were talking about the
control doing something in the IDE, rather than the IDE driving the control.
> Mind, a lot of this got easier with .NET,
Yes. I never got into the design mode of COM stuff.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> In contract-oriented programming, how could you possibly break the Order
> class by a change in the Customer class?
By changing the contract of the customer class that the order class relies
on. I haven't seen anything in a language where the order class could say
what parts of the customer class's contract it relies upon.
> As far as that is concerned, such a violation /could/ be detected by
> static code analysis (within limits regarding the complexity of the
> pre-/postconditions), or by running the application in debug mode with
> pre-/postcondition checks enabled (within limits regarding test coverage).
One would hope.
> I don't see where the C in ACID could be verified any differently.
It's more mathematical. Of course, it's harder to enforce everything in SQL
that you can express in (say) Eiffel.
> In Java, if you'd be smart you wouldn't declare function arguments as of
> a certain /class/ type, but of a certain /interface/ type. You can then
> easily "upgrade" to a more powerful type without changing any existing
> code (except for the actual container object creation).
Right.
> In other OO programming languages, you could do the same using the type
> names of abstract base classes instead of whatever actual implementation
> is used.
Right.
> If you did your homework properly, most OO languages will allow you to
> pull off the stunt even without recompiling most of the code.
Probably. But ... so? :-)
>
>> The point I was making is that there are lots of paradigms
>
> I presume this sentence was left incomplete? (Otherwise: Erm... yes,
> there are indeed lots of paradigms :-))
Sorry. There are lots of paradigms that let you do things like change the
type of a variable without having to have OO.
> But my primary point was that the OO /paradigm/ was highly influential
> in the creation of such type libraries - and that a non-OO approach
> doesn't get you there, unless you somehow "emulate" OO behavior.
Ehn. I'll disagree. I'll agree that container classes and GUIs both
benefited tremendously from an OO treatment, but I'll also assert that
non-OO modules and libraries (say, Ada83's) did nicely without the need for OO.
> In the case of the STL, the library in a sense uses a "static OO" model:
> The implementing classes are /designed/ to be interchangeable without
> code change (to the extent that they implement the same "concept"); they
> are /designed/ to use the same function names and parameters for the
> common functionality. The only thing they lack is a language that allows
> them to carry this flexibility over to run-time.
Well, yes. But that doesn't make them designed based on OO, any more than
UNIX's file system design was based on OO just because everything was a file
and used the same read and write calls.
>>> Note that data encapsulation /is/ an OO trait.
>>
>> It's a trait of a lot of languages. It's not the definitive trait of OO.
>
> This discussion seems familiar to me. I'd say it is /the/ most important
> trait of OO.
Yes. But it's not definitive. You can't have OO without encapsulation, but
there are many ways to have encapsulation without OO. The container example
you gave was all about encapsulation, not OO.
>> Does the STL's dequeue inherit from the STL's stack, or vice versa?
> No, but they both "inherit" from the same "concepts".
Um, ... No. Have you ever worked with a modular language that *isn't* OO?
Ada, Modula-3, something like that?
> And, as you say yourself, subclassing and inheritance is one of the
> primary defining features of /class-based/ OO. Given that there is
> non-class-based OO, obviously subclassing and inheritance /cannot/ be
> the primary defining features of OO in general.
I don't think there is a primary *defining* feature of OO in general.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka wrote:
> Darren New schrieb:
>> Darren New wrote:
>>> Erlang? Tcl? LISP?
>>
>> Actually, Ada can do this too, I'm pretty sure, even without using its
>> OO features.
>
> "Non-OO mainstream (imperative) language"?
>
> These languages all don't appear to fit that bill.
You don't think Ada or Tcl is mainstream? Just because you haven't run into
them doesn't mean they're not widely used.
Heck, many of the GUIs you see out there are based on Tk, which is based on
Tcl, which isn't OO. Fire up Python's IDLE, for example, and note that it
has a Tk logo in the corner.
> Though it wouldn't stand in the way of that.
To some extent it would, depending on how your OO is integrated with the
rest of your system. OO tends to have many references to one object
scattered about in other objects. You have to avoid that if you're going to
incrementally upgrade code as it runs.
--
Darren New, San Diego CA, USA (PST)
I ordered stamps from Zazzle that read "Place Stamp Here".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> The real problem is that most hackware is written by people who don't
> know what they want. They don't figure out what they want to code to do
> before they write the code.
Personally, I don't know how the program is going to work until I've
figured out how to write it.
(Which probably just means I always implement my programs in the way
that's easiest for me to program...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Automatic code generation from tools has been the subject of wishful
>> thinking for decades. Yes, CASE tools do exist. But where are they
>> used, and how powerful are they really?
>
> I think part of the problem is that you can't go back. You generate the
> code from the CASE tool, and then when you modify the code, you can't
> generate the CASE tool files from it.
Well, when you compile a C program, you don't then edit the generated
machine code. You edit the original C program and recompile.
Similarly with CASE, you edit in the case tool and then regenerate the
source code.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> ...which would just mean writing programs as mathematical statements
>> rather than lists of instructions. It would just be another
>> programming language. And, you know, people have argued that
>> programming in Haskell is like programming with mathematics, so...
> >
>> [One might also mention Mathematica.]
>
> Another fallacy of that time (and possibly with the functional
> programming approach) was the assumption that computer programs would
> always have the purpose of solving inherently mathematical problems -
> and that programming would therefore always be done by studied
> mathematicians.
>
> Now I guess the math required to program a word processor or an e-mail
> client is not /that/ complicated :-)
Some people might retort that too few programmers realise the deep
mathematical structure of the programs they're trying to implement. :-P
For example, Darcs is a version control system, much like RCS or CVS
are. But Darcs has an "algebra of changesets". Basically this dictates
the possible ways in which changesets can be applied. (If you think this
is barking mad, recall that databases are based on the relational
algebra, and that works just fine.)
To my knowledge, nobody has written a word-processor or e-mail client in
Haskell yet. But they have written an IRC bot, and a text editor along
the lines of Emacs. [Possibly the least-usable text editor in history...]
"Mathematics" isn't just about calculating things, you know.
> Unfortunately, the functional approach is quite brain-wrecking for
> anyone not trained in university-level mathematical thinking - or so it
> appears to me.
Heh, well... I suspect it only appears that way due to the strange
notation and unusual technical terms. I have no mathematical training of
any description at all, and I can work it...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4-10-2009 10:51, Orchid XP v8 wrote:
> Darren New wrote:
>
>> The real problem is that most hackware is written by people who don't
>> know what they want. They don't figure out what they want to code to
>> do before they write the code.
>
> Personally, I don't know how the program is going to work until I've
> figured out how to write it.
>
> (Which probably just means I always implement my programs in the way
> that's easiest for me to program...)
Next time, after you finished it, try to document how and especially why
it works. Just as an exercise. I bet you end up documenting (and
programming) something more efficient and robust.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
