Although aspect-oriented programning looks interesting and having
better defined platform targets would be useful (especially for UI
layouts) I don't see why you're lumping macros into all this.
Targeting code has nothing to do with macros, even if many people use
macros to accomplish that end.
Personally, I want macros to make up for a lack of inlining. Mars has
said in the past that RB would more likely get auto-inlining rather
than user-defined inlining, so although macros are useful for
shortening/reusing/targeting code they are also intrinsically inlined
(by a pre-process rather than the compiler) and would fill a void in
RB's functionality. Like most other things, macros can be as ugly or
as elegant as you make'm - if MFC macros bug you, then don't do stuff
like that ;)
Frank.
<http://developer.chaoticbox.com/>
On 27-Nov-06, at 8:52 AM, Daniel Stenning wrote:
Here is a Wiki for aspect orientated programming should you or
anyone else
be interested. I think such functionality could be a way of making
RB stand
out from the "crowd" and at the same time adopt some of the latest
thinking
and ideas in software engineering.
http://en.wikipedia.org/wiki/Aspect-oriented_programming
On 27/11/06 13:47, "Daniel Stenning" <[EMAIL PROTECTED]> wrote:
Macros in my opinion should be only about selecting code portions
dependent
on current platform or "environment". I think there are better
modern
approaches to solving those issues. Some sort of "layer" based
approach as
found in Aspect Oriented software tools and languages comes to
mind, where
there are clear seperations between code intended as the "core
logic" of an
application and aspects of implementation, error trapping and
platform
specialisation.
I just have a bad feeling about macros. Just look at the mess in the
Windows Win32 and MFC API. Not to mention typedefs. All used for
good
reasons. But if we can avoid them so much the better.
I would prefer to see some sort of IDE functionality that some how
hid
platform specific code, according to some selector, rather than
#if tests
throughout the code, or macro functions. I would say though that
I would
welcome the ability to set any function/method as #inline - which
could be
argued to be just a type safe form of macro....
One would then be able to switch between different "views"
dependent on
platform or just a name. so there could be a "view" for debug,
beta and
release mode, as well as view layers for specific platforms. Have
to admit I
don't have any firm picture of how exactly this would be
implemented, but
then that's down to will and brain brawn.
On 26/11/06 18:05, "Lars Jensen" <[EMAIL PROTECTED]> wrote:
only a built in RB Assert syntax would allow us to include the
test string
So would macros, which would also allow you to make your asserts
zero-footprint as you like. As a bonus, they would allow you (and,
more importantly, me) to eliminate much duplicate code. They are
a far
more general and useful response to the Assert impulse.
lj
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
