mirror of
https://github.com/quasar/Quasar.git
synced 2026-04-25 15:25:59 +03:00
[PR #147] [MERGED] Changed the send method's parameter type for client/server #1003
Labels
No labels
bug
bug
cant-reproduce
discussion
duplicate
easy
enhancement
help wanted
improvement
invalid
need more info
pull-request
question
wont-add
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/Quasar#1003
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
📋 Pull Request Information
Original PR: https://github.com/quasar/Quasar/pull/147
Author: @yankejustin
Created: 5/19/2015
Status: ✅ Merged
Merged: 5/19/2015
Merged by: @MaxXor
Base:
master← Head:Improvements📝 Commits (4)
d20dcc3Merge pull request #3 from MaxXor/master6c12e0bRespect the packet's type3990494Fixed redundant type specification983068eFixed redundant type specification📊 Changes
92 files changed (+94 additions, -94 deletions)
View changed files
📝
Client/Core/Client.cs(+2 -2)📝
Client/Core/Packets/ClientPackets/DesktopResponse.cs(+1 -1)📝
Client/Core/Packets/ClientPackets/DirectoryResponse.cs(+1 -1)📝
Client/Core/Packets/ClientPackets/DownloadFileResponse.cs(+1 -1)📝
Client/Core/Packets/ClientPackets/DrivesResponse.cs(+1 -1)📝
Client/Core/Packets/ClientPackets/GetLogsResponse.cs(+1 -1)📝
Client/Core/Packets/ClientPackets/GetProcessesResponse.cs(+1 -1)📝
Client/Core/Packets/ClientPackets/GetStartupItemsResponse.cs(+1 -1)📝
Client/Core/Packets/ClientPackets/GetSystemInfoResponse.cs(+1 -1)📝
Client/Core/Packets/ClientPackets/Initialize.cs(+1 -1)📝
Client/Core/Packets/ClientPackets/MonitorsResponse.cs(+1 -1)📝
Client/Core/Packets/ClientPackets/ShellCommandResponse.cs(+1 -1)📝
Client/Core/Packets/ClientPackets/Status.cs(+1 -1)📝
Client/Core/Packets/ClientPackets/UserStatus.cs(+1 -1)📝
Client/Core/Packets/ServerPackets/Action.cs(+1 -1)📝
Client/Core/Packets/ServerPackets/AddStartupItem.cs(+1 -1)📝
Client/Core/Packets/ServerPackets/Delete.cs(+1 -1)📝
Client/Core/Packets/ServerPackets/Desktop.cs(+1 -1)📝
Client/Core/Packets/ServerPackets/Directory.cs(+1 -1)📝
Client/Core/Packets/ServerPackets/Disconnect.cs(+1 -1)...and 72 more files
📄 Description
Why?
The generic type (restricted to those inheriting IPacket) is accepted by the Send method for the client and the server. I knew that this functionality is used to restrict the type of the packet, and the generic type is used to specify exactly what the type was. However, because the parameter was of the type IPacket in this case (not necessarily defined in type, rather than being required to inherit IPacket of course), the send method would end up boxing the parameter (packet), then would later unbox it with the type T given to the Send method. Doing this eliminates the need to box/unbox the packet.
Also, type T would be required to be of the type assigned to the parameter (packet), ensuring safety of the types being used.
Safety
Imagine we call
Send(bracket)GetProcesses(end_bracket)(this)where "this" is a reference to a type of packet that cannot cast in a manner that allows serialization of the packet. It would obviously fail, and would result in (likely) unexpected and hard to find behavior. There is no need in our case to specify the specific type of the parameter because the generic type (as defined by the parameter) will be determined for us.Is this concept against the implementation of ProtoBuf?
Nope. ProtoBuf actually follows this design already:
public static void SerializeWithLengthPrefix(bracket)T(end_bracket)(Stream destination, T instance, PrefixStyle style)
{
SerializeWithLengthPrefix(bracket)T(end_bracket)(destination, instance, style, 0);
}
Additional Notes
- If necessary, one can still achieve the desired behavior of specifying a more-specific base type (T), if and only if type (T) specified can inherit both "IPacket" and the type of the parameter specified. - The List type also uses this design. This is why (when you provide the object when constructing a List) you do not also have to specify the type again. This feature means that providing an object to the object receiving the generic type naturally ensures type safety at compile-time.🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.