ID:138518
 
To revive a question: Will the new approach to Topic() approach work with data objects?

I'm preparing my forum code for public release, and I'd really like to switch it from my current global Topic() approach to an object-based on first...
I underestimated Dan: Topic() does indeed work for all objects. Example:

var/testobj/globalTestObj = new()

testobj
Topic(href)
if(href=="futz")
usr << "Yay!"

mob/verb/futz()
usr << "Click <a href=#\ref[src]futz>here</a>!"

will send the "futz" href to globalTestObj.
In response to Tom H. (#1)
On 7/3/00 3:32 pm Tom H. wrote:
I underestimated Dan: Topic() does indeed work for all objects. Example:

var/testobj/globalTestObj = new()

testobj
Topic(href)
if(href=="futz")
usr << "Yay!"

mob/verb/futz()
usr << "Click here!"

will send the "futz" href to globalTestObj.


Dan is da bomb!

I apologize for not testing this myself -- I was asking in haste before leaving for the day, and if it didn't work for me wouldn't be sure if that was by design or bug.
In response to Deadron (#2)
and if it didn't work for me wouldn't be sure if that was by design or bug.

Such confidence! I am flattered.

I debated a bit about whether Topic() was really appropriate in general data objects, since I want to intrude as little as possible on them with pre-defined procedures and variables. However, when I realized that for generality the \ref[] macro and tag variable should be made to work for data objects too, I couldn't help throwing in Topic() as well.

None of that has any impact on memory usage, so data objects don't carry around any more baggage than they used to.
In response to Dan (#3)
On 7/4/00 6:48 am Dan wrote:
and if it didn't work for me wouldn't be sure if that was by design or bug.

Such confidence! I am flattered.

I debated a bit about whether Topic() was really appropriate in general data objects, since I want to intrude as little as possible on them with pre-defined procedures and variables. However, when I realized that for generality the \ref[] macro and tag variable should be made to work for data objects too, I couldn't help throwing in Topic() as well.

None of that has any impact on memory usage, so data objects don't carry around any more baggage than they used to.


I agree with both instincts -- in general it's probably best to not intrude on data objects, but in the cases mentioned it is such a big win that it is worth whatever moral crime may be in progress.

So far, in fact, I use Topic() ONLY for data objects...
In response to Tom H. (#1)
On 7/3/00 3:32 pm Tom H. wrote:
I underestimated Dan: Topic() does indeed work for all objects. Example:

var/testobj/globalTestObj = new()

testobj
Topic(href)
if(href=="futz")
usr << "Yay!"

mob/verb/futz()
usr << "Click here!"

will send the "futz" href to globalTestObj.

This code sample has a couple of problems, in case anyone tries to use it in the future.

To work, the URLs must be like this and should not use src in this case:

href=\"byond://#\ref[globalTestObj]futz\"
In response to Deadron (#5)
On 7/5/00 2:12 am Deadron wrote:

To work, the URLs must be like this and should not use src in this case:

href=\"byond://#\ref[globalTestObj]futz\"

You are right about the globalTestObj thing. My mistake.

I just figured out why we are disagreeing on byond://. You are probably using the link inside the browser, which does require this restriction. The normal output panels uses byond:// by default.

I guess we should be consistent. The reason byond:// isn't the default inside the browser is so that normal html docs (with implicit #links will work); therefore http:// is the default. The reason byond:// is the default inside the output is that most output links will call byond functions rather than http ones. But then certain elements can be sent to both panels. Do you like this current system?

I guess to be safe we should always put the protocol in our examples, and you coders should probably do the same. This is kind of an irritating issue.
In response to Tom H. (#6)
On 7/5/00 2:20 am Tom H. wrote:
I guess we should be consistent. The reason byond:// isn't the default inside the browser is so that normal html docs (with implicit #links will work); therefore http:// is the default. The reason byond:// is the default inside the output is that most output links will call byond functions rather than http ones. But then certain elements can be sent to both panels. Do you like this current system?

I guess to be safe we should always put the protocol in our examples, and you coders should probably do the same. This is kind of an irritating issue.


Well in my code I wouldn't want to assume where the output is going. For example, my email system currently uses the output area, because I wrote it before the browser was available. Soon I will probably switch it. But moreso, it's easy to imagine generating text that might go one place or the other depending on the situation -- so I'm happy to always use the byond:// prefix.

Also, I'm rather anal about typing things anyway.