SitePoint Sponsor

User Tag List

Page 13 of 13 FirstFirst ... 3910111213
Results 301 to 325 of 325
  1. #301
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    All your DB Connector cares about is that $config->get('DBName'), etc. exist. It's all about the interface.
    Yeah. But for interoperability, get() is not what matters, DBName is. So to ensure that it's pluggable, having an interface with getDBName() in it seems more reasonable.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  2. #302
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    699
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by mx2k

    SPL is the standard php library....which houses the exception class, but can be turned off in the .ini file or when compiled.
    Can you provide a link to this one? Accoding to the PHP site, SPL provides additional Exceptions as well as various interfaces and classes. But the Exception class itself as well as the try/catch/throw mechanism is part of the core. Nor could I find any documentation on an ini setting for disabling exception processing.

    There have been some bug reports concerning throwing exceptions inside of __get. The ones from several years ago have been marked as fixed. One from June 2004 is inactive.

  3. #303
    SitePoint Guru
    Join Date
    Nov 2002
    Posts
    841
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    So many excellent points here. I wish I had time to reply to more.
    Quote Originally Posted by arborint
    I think of Keyed as the object form of a PHP associative array.
    Isn't there an interface in SPL for that already?

    I think of this as a defining the properties facet of a PHP component specification.

    Quote Originally Posted by arborint
    We really should not underestimate the powerful benefits of this. I have been meaning to itemize this list that lastcraft rolls out naturally. If your Request, Config, DB Row, Template, and Response all use the same container interface then many things are simplified and interesting possibilities occur.
    Such is the power of components. All of those things are components.

    Earlier you asked "are we trying to ... create a standard interface for simple keyed containers?"

    Simple keyed containers are the properties facet of a component API.

    The first post of the thread brought up the possibility of modifying PHP itself. The name of the thread is "standards & interface." Properties can be a standard just as well as it can be an interface.

    I see three main posssibilities:
    1. Think "inside the PHP box."
      Define an interface with set()/get(). I have NO problem with this. WACT has exactly this now. Seriously, I have no problem with this. WACT has had DataSource components in it since day one. I've been working with a set()/get() interface for years. And yet...
    2. Think "I am one with the box I'm in."
      Use a standard instead of an interface. Access properties with -> and deal with the flaws involved with implementing accessor methods using __get and __set. Longer term, I'm looking here. Conceptually, I think -> is the place to be. It feels more PHP like. Its more concise, easier to read and understand. Yet, there are so many rough edges.
    3. Think "Am I in the right box?"
      My current thinking is that the best long term solution is to attempt to get native accessor methods in PHP. I am seriously looking at implementing this myself and trying to get it in PHP 6, then taking WACT from directly from 4 to 6.


    I think __get and __set on an interface is a dead idea.

    Anyway, I'm glad to see some of the PHP compatibility issues being raised:
    What if you set a property that isn't there? (create one or error?)
    What if you get a property that isn't there? (return NULL or error?)
    What if you hasProperty a property that exists and is NULL? (return TRUE or FALSE?)

  4. #304
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by Selkirk
    Isn't there an interface in SPL for that already?
    I don't think ArrayObject is in the spirit I was thinking of. It exists to support ArrayIterator from what I can see.

    Quote Originally Posted by Selkirk
    I think of this as a defining the properties facet of a PHP component specification.

    Such is the power of components. All of those things are components.

    Earlier you asked "are we trying to ... create a standard interface for simple keyed containers?"

    Simple keyed containers are the properties facet of a component API.
    I think a minimum standard for a component such as we are discussing would be a step toward interop between the absurd number of classes in PHP. And interop means apples and apples comparison which will act to cull all the low quality variations (i.e. those with out unit tests)

    Quote Originally Posted by Selkirk
    The first post of the thread brought up the possibility of modifying PHP itself. The name of the thread is "standards & interface." Properties can be a standard just as well as it can be an interface.
    Given the problems around PHP5 I think it may be time to be more involved in PHP internals because something is not right.

    Quote Originally Posted by Selkirk
    I see three main posssibilities:
    1. Think "inside the PHP box."
      Define an interface with set()/get(). I have NO problem with this. WACT has exactly this now. Seriously, I have no problem with this. WACT has had DataSource components in it since day one. I've been working with a set()/get() interface for years. And yet...
    2. Think "I am one with the box I'm in."
      Use a standard instead of an interface. Access properties with -> and deal with the flaws involved with implementing accessor methods using __get and __set. Longer term, I'm looking here. Conceptually, I think -> is the place to be. It feels more PHP like. Its more concise, easier to read and understand. Yet, there are so many rough edges.
    3. Think "Am I in the right box?"
      My current thinking is that the best long term solution is to attempt to get native accessor methods in PHP. I am seriously looking at implementing this myself and trying to get it in PHP 6, then taking WACT from directly from 4 to 6.
    I think you clearly state the options or steps to nirvana. But my main point in all of this is that PHP is stuck at number 0. If we can get a good part of the PHP community to start using something like minimal version of the WACT DataSpace (see Skeleton DataSpace) then we can get PHP on the road from 1 -> 2 -> 3. But I truely believe we need to get a critical mass using get()/set() containers to move forward.

    Quote Originally Posted by Selkirk
    I think __get and __set on an interface is a dead idea.
    And good riddance.

    Quote Originally Posted by Selkirk
    Anyway, I'm glad to see some of the PHP compatibility issues being raised:
    What if you set a property that isn't there? (create one or error?)
    What if you get a property that isn't there? (return NULL or error?)
    What if you hasProperty a property that exists and is NULL? (return TRUE or FALSE?)
    I really don't have an opinion about exceptions because I think the jury is still out on how to best use them in PHP. My point all along has been that people who use PHP have an expectation (good or bad) that things will work a certain (mushy) way. That's why I proposed, whether they throw exceptions or not, that get/set have the same feel as associative arrays, which means using NULL. Because the reality is that the current container standard in PHP is the associative array. It is used for all the things that we want people to use containers for. So we should not annoy unnecessarily.
    Christopher

  5. #305
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    My point all along has been that people who use PHP have an expectation (good or bad) that things will work a certain (mushy) way. That's why I proposed (...) that get/set have the same feel as associative arrays, which means using NULL. Because the reality is that the current container standard in PHP is the associative array. It is used for all the things that we want people to use containers for. So we should not annoy unnecessarily.
    Very true.

  6. #306
    SitePoint Addict mx2k's Avatar
    Join Date
    Jan 2005
    Posts
    256
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    http://www.php.net/~helly/php/ext/spl/spl_8php.html

    http://www.php.net/~helly/php/ext/spl/

    but it looks like your right and they have the exception class in the core engine now, according to the spl documentation.

    i know i read somewhere that the spl could be turned off since its an extention, but i can't remember exactly where.

  7. #307
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I really don't have an opinion about exceptions because I think the jury is still out on how to best use them in PHP. My point all along has been that people who use PHP have an expectation (good or bad) that things will work a certain (mushy) way. That's why I proposed, whether they throw exceptions or not, that get/set have the same feel as associative arrays, which means using NULL. Because the reality is that the current container standard in PHP is the associative array. It is used for all the things that we want people to use containers for. So we should not annoy unnecessarily.
    But get()/set() are annoying and very unlike array access. Have you considered using straight arrays? ) that's tongue-in-cheek because I've lost heart until we get to general containers)

  8. #308
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    But get()/set() are annoying
    I am starting to think being annoying to you might become one of our requirements for these interfaces.
    Quote Originally Posted by jayboots
    and very unlike array access. Have you considered using straight arrays? ) that's tongue-in-cheek because I've lost heart until we get to general containers)
    I think they are very alike for two reasons:

    1. You use a scalar key to access the data.

    2. As I said above, the current container standard for PHP is the associative array. So if we can move programmers to a simple get()/set() container we have them thinking about objects as containers. That is the first goal.
    Christopher

  9. #309
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I am starting to think being annoying to you might become one of our requirements for these interfaces.
    If that is your definition of success, then job well done! lol

    Quote Originally Posted by arborint
    I think they are very alike for two reasons:
    1. You use a scalar key to access the data.

    2. As I said above, the current container standard for PHP is the associative array. So if we can move programmers to a simple get()/set() container we have them thinking about objects as containers. That is the first goal.
    I oppose the idea that this is making things simpler particularly since it 1) changes the way people already do things, 2) doesn't add anything to what is already available. For example, this very interface already exists in SPL: http://www.php.net/~helly/php/ext/spl/interfaceArrayAccess.html -- oh wait, it includes an unset so surely it is not acceptable here. *shrug*

  10. #310
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    I oppose the idea that this is making things simpler
    I can't imagine that you actually oppose making things simpler, nor does using a container make things simpler.
    Quote Originally Posted by jayboots
    particularly since it 1) changes the way people already do things,
    Not really, currently if you have a scaler key and they want to save data somewhere using that key, then associative arrays are your container
    Quote Originally Posted by jayboots
    2) doesn't add anything to what is already available.
    I certainly goes well beyond associative arrays (when they are used as containers). And, yes there are many similar things out there, but no minimum standard.
    Quote Originally Posted by jayboots
    For example, this very interface already exists in SPL: http://www.php.net/~helly/php/ext/spl/interfaceArrayAccess.html -- oh wait, it includes an unset so surely it is not acceptable here. *shrug*
    I think this is a prime example of what is wrong with SPL. There is general agreement that a container is something that PHP needs, yet SPL goes off and reimplements array. The PHP array has to be about the most flexible well supported thing if its kind in any programming language. Giving it native object support like Selkirk has suggested in the logical next step. But SPL seems to be aiming at Java 5 years ago as its target.
    Christopher

  11. #311
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    I can't imagine that you actually oppose making things simpler, nor does using a container make things simpler.
    Of course I don't oppose making things simpler, if they are indeed making things simpler. I'm sure we all agree on this point; however, we seem to disagree on the criteria for something being simpler or not.

    Quote Originally Posted by arborint
    Not really, currently if you have a scaler key and they want to save data somewhere using that key, then associative arrays are your container
    Hmm. Be sure that I most certainly understand these primitive principles. My point is that get/set introduces arbitrary new syntax and moreso goes in a direction that is really based on Java principles (explicit method access). The reason some folks have suggested [] access and others (like myself) -> access is just because in PHP people already use [] for arrays and -> is natural in PHP since it exposes public members, unlike some certain other languages. Ignoring this ignores the very things that makes PHP so simple, as far as I am concerned.

    Quote Originally Posted by arborint
    I certainly goes well beyond associative arrays (when they are used as containers). And, yes there are many similar things out there, but no minimum standard.
    I don't understand your meaning here.

    Quote Originally Posted by arborint
    I think this is a prime example of what is wrong with SPL. There is general agreement that a container is something that PHP needs, yet SPL goes off and reimplements array. The PHP array has to be about the most flexible well supported thing if its kind in any programming language. Giving it native object support like Selkirk has suggested in the logical next step. But SPL seems to be aiming at Java 5 years ago as its target.
    If this is what you think, then perhaps you should reconsider what is being done with this current interface because from my POV that is EXACTLY what it is doing.

    At any rate, it has never been my intention to be an obstacle to this process. From the outset I stated my goals (exploiting PHP's dynamic features) and asked if it was appropriate for me to post into the thread. Perhaps the initial reaction that I received was not really in-line with the goals of this thread after all. That's not a problem for me and if you don't think I should participate further, just say so. After all, this much head-butting isn't that much fun, yes?

    best regards.

  12. #312
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by jayboots
    Hmm. Be sure that I most certainly understand these primitive principles. My point is that get/set introduces arbitrary new syntax and moreso goes in a direction that is really based on Java principles (explicit method access). The reason some folks have suggested [] access and others (like myself) -> access is just because in PHP people already use [] for arrays and -> is natural in PHP since it exposes public members, unlike some certain other languages. Ignoring this ignores the very things that makes PHP so simple, as far as I am concerned.
    I am not opposing -> access because I think it is inferior, I hope it is the long term solution. But it is PHP5 only and problematic even in PHP5.

    The difference between ->/[] access and get()/set() is that the latter is the simplest, minimum way to allow a separation between interface and implementation in both PHP4 and PHP5 right now.

    What I am supporting is coming up with a workable keyed access container that works now. The WACT DataSpace is a prime example of the utility of this. Selkirk is thinking ahead because DataSpace is a two year old idea for him. But it is new to much of the PHP world. If we can get people up to that point (and get a little interop between frameworks like Mojavi and WACT) then we can get a critical mass of programmers on the path that people like Selkirk and illusina are currently on.
    Quote Originally Posted by jayboots
    If this is what you think, then perhaps you should reconsider what is being done with this current interface because from my POV that is EXACTLY what it is doing.
    I think it depends on you thoughts about the difference between containers and arrays. Arrays are already well supported in PHP. Now if you want to add things like $array->count, I would be for that.

    Quote Originally Posted by jayboots
    At any rate, it has never been my intention to be an obstacle to this process. From the outset I stated my goals (exploiting PHP's dynamic features) and asked if it was appropriate for me to post into the thread. Perhaps the initial reaction that I received was not really in-line with the goals of this thread after all. That's not a problem for me and if you don't think I should participate further, just say so. After all, this much head-butting isn't that much fun, yes?
    I don't think anyone is an obstacle who is trying to understand the issues and working towards solutions. Going back to your first post, you said:
    Quote Originally Posted by jayboots
    Another problem is that all the interfaces in the world won't help anyone unless they are easy to implement in a particular system. As there is no set standard for a framework design in PHP, perhaps this is best place to start. Good luck though trying to get a consensus on that one Not that you need 100% buy-in, of course. I just think it would be a good starting point because it would help give a better picture of the types of things that you might want to see standardized.
    My feeling is that get()/set() best meets the "are easy to implement in a particular system" requirement for the current state of PHP. If PHP5 had been a wild success and had 80% adoption I would have a different opinion. But our reality is PHP4, little/no interop between frameworks, and people still asking "Should I use objects rather than procedural..." questions.
    Christopher

  13. #313
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    In PHP5, classes and interfaces share the same namespace (like it or not). So, should there be a standard like C#s prepending "I" to everything (e.g. IKeyed). I notice that the PHP docs and SPL give a nod toward name ending with "*able" (e.g. Keyable) but are hardly consistent.

    I am sure there are opinions, but is there any consensus on naming interfaces in PHP?
    Christopher

  14. #314
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I already prefix with "I" and also "A" for abstract, so I'm all for that.

  15. #315
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I like I

  16. #316
    eschew sesquipedalians silver trophy sweatje's Avatar
    Join Date
    Jun 2003
    Location
    Iowa, USA
    Posts
    3,749
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by kyberfabrikken
    I like I
    Shouldn't that be ILike
    Jason Sweat ZCE - jsweat_php@yahoo.com
    Book: PHP Patterns
    Good Stuff: SimpleTest PHPUnit FireFox ADOdb YUI
    Detestable (adjective): software that isn't testable.

  17. #317
    SitePoint Addict
    Join Date
    Aug 2003
    Location
    Toronto
    Posts
    300
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I should add that I still think it is not a good idea to take popular names on their own but rather to prefix with the project name, eg: ISIRKeyed or ISIR_Keyed or maybe just SIR_Keyed...or what-have-you. Amongst many factors, it should make google searches easier Also, since ISIR sounds like

    @sweatje -- lol

  18. #318
    ********* Victim lastcraft's Avatar
    Join Date
    Apr 2003
    Location
    London
    Posts
    2,423
    Mentioned
    2 Post(s)
    Tagged
    0 Thread(s)
    Hi.

    Please don't prefix. It just adds clutter, and there is no reason for class names to have the same names as interfaces. They are fundamentally different things. One's a role, the other is a capability. Prefixing is Hungarian notation without a point and will store up problems for when PHP gets namespaces.

    If you are going to prefix (again, please don't) then go InteropKeyed. Acronyms just create confusion with captilaisation, and abreviations just cause confusion full stop.

    yours, Marcus
    Marcus Baker
    Testing: SimpleTest, Cgreen, Fakemail
    Other: Phemto dependency injector
    Books: PHP in Action, 97 things

  19. #319
    Non-Member
    Join Date
    Jan 2003
    Posts
    5,748
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Nothing wrong with Prefixing interfaces and classes. There is absolutely no clutter at all just because you prefix the letter I to an interface, or prefix the term Abstract to an abstraction.

    Next thing you'll be saying, is that it's bad practice as well, to prefix your filenames, such as,

    Code:
    ifilter.class.php
    ...
    filters/login.class.php
    filters/authentication.class.php
    ...
    Developers have for years, been prefixing their interfaces and classes, and no doubt it's going to continue for some time yet. It's down to personal preference, and has little to do with namespace clutter.

    Do you have anything concrete on how using I and Abstract could be a problem Marcus? I just don't see what the problem is. For whatever amount of confusion that could arise, then one relatively easy solution to that is clear documentation.

    Some businesses require that you have prefixes, how do you convince them to drop them? How do you convince them that their organisational standards are confusing?

  20. #320
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Well, as ever I am sorry when I ask about naming. I also think that the name matters less than whether people acutally use the interface.

    One thing that came up in the course of my back and forth with jayboots is that there are two different design spheres in PHP at the moment.

    1. There is the PHP4/PHP5 sphere where the focus is having things work for the current versions of PHP but with an upward design path,

    2. The PHP5/PHP6 sphere where PHP4 (and its problems) are abandoned, so there are more advanced OO possiblities.

    Having people in those different spheres attempt to come up with a common design is a futile, interseting at times, but a waste of time. So I would propose that in the future we first determine in which design sphere we are working.

    So, after all of that, is there any real value or interest in the interface Keyed in the PHP4/PHP5 sphere:
    PHP Code:
    interface Keyed {
    function 
    get($key);
    function 
    set($key$value);
    function 
    has($key); 
    Christopher

  21. #321
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Please don't prefix.
    I'll second that. "IHurtToRead" is the devil's work, I tell ye

  22. #322
    SitePoint Guru 33degrees's Avatar
    Join Date
    May 2005
    Posts
    707
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by arborint
    So, after all of that, is there any real value or interest in the interface Keyed in the PHP4/PHP5 sphere:
    PHP Code:
    interface Keyed {
    function 
    get($key);
    function 
    set($key$value);
    function 
    has($key); 
    Unless I'm mistaken, the whole reason for defining this interface was to promote interoperability between the components that implement it, and that's as much of a concern under php4 as it is under php5. The fact the php4 doesn't actually have an 'implements' keyword is besides the point.

  23. #323
    SitePoint Guru dagfinn's Avatar
    Join Date
    Jan 2004
    Location
    Oslo, Norway
    Posts
    894
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by lastcraft
    Please don't prefix.
    For some opinions on this issue, read
    DontDistinguishBetweenClassesAndInterfaces.
    Dagfinn Reiersøl
    PHP in Action / Blog / Twitter
    "Making the impossible possible, the possible easy,
    and the easy elegant"
    -- Moshe Feldenkrais

  24. #324
    simple tester McGruff's Avatar
    Join Date
    Sep 2003
    Location
    Glasgow
    Posts
    1,690
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    The fact the php4 doesn't actually have an 'implements' keyword is besides the point.
    Agreed. I do use interfaces a lot in v4 although it's really just documentation:

    PHP Code:
            class Foo // implements Bar
            
    {
                
    // etc 
    Whenever I find an interface, a skeleton class goes in an "interfaces" folder. Again it's really just documentation although they're also handy for creating mocks.

    If hints are required in the code you come up with fair enough. If not, it might be nice to be able to use it in v4. Freelancers working on smaller scale web sites will have to support v4 for some time to come.

  25. #325
    SitePoint Wizard
    Join Date
    Aug 2004
    Location
    California
    Posts
    1,672
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by 33degrees
    Unless I'm mistaken, the whole reason for defining this interface was to promote interoperability between the components that implement it, and that's as much of a concern under php4 as it is under php5. The fact the php4 doesn't actually have an 'implements' keyword is besides the point.
    I agree completely, my hope is that PHP4 code would adhere to this standard as well as PHP5 code.

    I think the goal here is to get minimal, useful standards that we can _agree_ on. The reason I think it is important is that I see people like Selkirk and illusina and wei travelling down interesting path(s) with frameworks and the rest of the PHP world stuck in the doldrums. A little interop between frameworks and some standards to use for all of these common classes like Request/Response, Template, DB Record Set, Config, etc. etc. and it might put a little wind in PHP's sails.

    I should note that I have (right or wrong) promoted including PHP4 compatiblity into the mix because I think it is important to get people to start using basic containers. By the time that (hopefully) happens, maybe we will have PHP5/PHP5 magic move us another step forward with things like accessor based containers, DI (using interface/container introspection info), etc. etc.
    Christopher


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •